Whether you are a developer already knowledgable in programming languages, or a tech enthusiast looking to broaden your understanding of coding, Punchkick has put together a quick resource for everyone interested in the top five languages used for programming mobile native and web applications. For those of us that don’t speak geek, we’ve included a glossary of some commonly used terms.
1. Java: Java is the “default” and recommended language for Android development. It’s an object-oriented* language very similar in style and syntax to C/C++, making it easy to learn when coming from those languages. A convenient feature that Java uses is automatic garbage collection, which means programmers don’t have to manually deallocate memory and makes development easier. Also, Java code is “write once, run anywhere”, so code written in Java can be run on any platform that has a supported JVM (Java Virtual Machine). This is achieved by compiling Java code into “bytecode” that gets run on the JVM regardless of the JVM’s underlying platform (Windows, Mac, Linux, Unix, etc).
Android runs a different type of virtual machine called Dalvik, which is optimized for embedded mobile devices. Dalvik is not a JVM, and it won’t run standard Java bytecode. Rather, Android code must be further converted from standard Java bytecode into Dalvik compatible .dex files. Android’s SDK* includes a tool called “dx” that performs this conversion.
2. Objective-C: Objective-C is the “default” and recommended language for iOS and, like Java, is object-oriented. There are a variety of defining features in Objective-C. Categories, for example, allow the adding of new methods to existing classes provided by Apple. Automatic Reference Counting (ARC) memory management is handled by calls inserted by the compiler as opposed to having the overhead of garbage collection. Objective-C is known for long and expressive names for methods and variables; this is called expressive syntax and allows for clearer code. Strict superset of C means that any code that can be compiled in C, can also be compiled in Objective-C, which provides great flexibility for leveraging existing libraries*.
3. C#: C# is the “default” and recommended language for Windows Phone 7/8/Surface and is a completely Object-Oriented language. If coming from a background in classical languages (C, C99), it’s very easy to pick up this language, compared to Java or Objective-C. In C#, a deep understanding of the language is not necessary in order to prototype something basic that is both functional and appealing. This language has a very strong community behind it, so information and code snippets are readily available for Windows Phone 7/8/Surface platforms. There’s also a large open source* community behind the language. C# has been around for a long time and gets a lot of TLC from Microsoft, who cares and listens to it’s developer community.
Visual Studio and Blend are excellent tools for developing and designing mobile apps. With no experience with VS, one can jump right in and start creating something. Unlike Xcode, Visual Studio has an actual emulator* rather than a simulator* for testing and running the applications (through HyperV), so one can be fairly confident that what is seen in the emulator is what is going to be experienced on actual hardware.
4. PHP: PHP is the server-side language of choice here at Punchkick. PHP isn’t device specific, since it runs on the server, and is great for developing APIs* for mobile apps. PHP is built from the ground up to support web protocols, making it an ideal option for powering the mobile web. As mobile web apps become more advanced on the client-side (using JavaScript and HTML5), they are increasingly API-driven on the server-side. PHP’s built-in support for the HTTP protocol and Zend Framework’s useful libraries, for building clean and efficient APIs, makes PHP very attractive for building out the server-side aspect of mobile web apps.
An interesting aspect of PHP is how far it’s come in the last few years. New language features are constantly being added, making it a more fun, interesting, and efficient language to develop in. Additionally, the larger community of PHP developers, particularly around Zend Framework and the Symfony framework, provide a true wealth of information and knowledge on what can be done with PHP today.
5. JavaScript: JavaScript is the “default” language of the web, and has gained much popularity within the last several years. JavaScript is commonly associated with Java however, the two languages have no relations beyond their initial structural implementations (making them look slightly similar), and are really quite different. JavaScript is a dynamically-typed prototype-based functional* scripting language with auto garbage collection – allowing it to be written in extremely unique and expressive manners that just can’t be done in a compiled language. However, the most important benefit that JavaScript has to offer is its ubiquitous runtime – though differing from device to device – which makes JavaScript the most accessible language for users and developers alike. If you have a web browser, you can run or develop a JavaScript application.
It’s no surpise that the JavaScript community is bustling with knowledgeable developers and chock-full of helpful libraries. If you encounter a roadblock while working with JavaScript, or any of its varying environments, there’s a good chance that it’s already been solved – either by a simple answer or the use of (one of the many) libraries available. JavaScript is an extremely powerful language, and as mobile devices continue to improve for their support and performance for it – the line between “native apps” and “web apps” will undoubtedly fade.
*Glossary of terms:
Object-Oriented Programming: Refers to a method of grouping similar functionality and using those objects in an objective way, rather than working with procedural code (one line of code after another with no grouping). By using object-oriented programming, we can group data and data access methods together easily so, if we want to use them or expand upon them, we can find them in the same spot, rather than all over the place.
SDK: A Software Development Kit is a collection of tools that developers use to help them work with a certain language, platform, or device. Examples of this would be XCode and Visual Studio. Generally, SDK’s have a built in editor for editing code and connections to work with simulators/emulators/
Library: A library is a useful piece of code that operates independently of the applications it can be used in. It is a smaller component that can be used across multiple applications with no adaptation. Examples would be jQuery, ExtJS, and ASIHTTPRequest. You use this code in your application, but you never modify it.
Open Source: An open source application is an application whose source code is publicly available for reviewing, distribution, and editing – depending upon the license. It’s a way of giving back to the community, allowing others to contribute to the project, make it better, find issues, and make the application more secure.
Emulator: An emulator is a piece of software that emulates the functionality of another device. Running something on a emulator is like running something on an actual device (such as an Windows Phone). What you see on the emulator is what you’re going to see on the actual hardware device. Visual Studio uses an emulator for debugging.
Simulator: A simulator is a piece of software that simulates the functionality of another device. It’s similar to an emulator, but different in that you aren’t emulating the hardware the software is running on as well. A simulator will give you a similar experience as one you’d see on a hardware device, but there might be some major differences (running on a different CPU than the hardware would, for example). XCode uses a simulator for debugging.
API: An Application Programming Interface allows developers to interface with another application to get information that the API service provides. Google Maps is a great example of this. They offer an API that allows developers to get information about maps and directions, so instead of having to solve that problem themselves, they can ask Google Maps to solve it. An API provides information in an easily manipulable way which a developer can use to interface with their application. The difference between and API and a Library is that a library is an internal tool which the developer uses and includes in his code, whereas an API is an external tool the developer uses to get information. Google Maps, Bing Maps, WordNik, and Weather.com all provide APIs.
Functional Programming: Functional programming is a programming paradigm that treats computation as the evaluation of math functions and avoids states and changing data. Functional programming emphasizes the use of functions to solve problems (these functions don’t change). Think lamda calculus, if you’ve ever taken it. If not, think Fibonacci sequence.
The 5 Commandments of Mobile Web Design
A one-size-fits-all approach to solving problems rarely seems to work in the real world, and the mobile Web is no different.
Up to this point, most mobile sites have been developed by re-hashing traditional Web content and squeezing it onto the small screen—an unfortunate “Mini-Me” approach to mobile Web design. The result? While the traditional Web becomes more useful and creative every day, the significance of the mobile Web has largely stalled. The mobile Web has yet to realize its awesome potential, and the problem isn’t a technology issue like you may be already thinking. The problem is design, or rather, a lack thereof, within the mobile medium.
1. The Mobile Web is Not the Little Sister of the Traditional Web.
What makes a mobile site so different?
It’s not the screen size—it’s the intent of the user. Very often, traditional Web users browse the Web for entertainment or to kill time. Even when traditional users need to perform work-related tasks, they are easily sidetracked by Twitter, YouTube, or any of the thousands of social networking sites.
Mobile users, on the other hand, typically browse the mobile Web when they are in need of specific information. These experiences tend to be much shorter than they are on the traditional Web, and users rarely browse for entertainment purposes. Let’s just be honest with ourselves—if a user could be in front of a computer, that’s where he or she would be.
Suppose that you were offered a chance to view a new Red Hot Chili Peppers music video on your phone. Would you actually navigate to the video and watch it, when you could just as easily view it on a speedy home computer? Re-purposing traditional Web content and stuffing it into a mobile browser is a recipe for disaster. Instead, it’s time to look at the mobile Web as a uniquely distinctive medium.
2. Give People What They Want, When They Want It.
All mobile Web users across the globe want the same thing: the ability, at any time, to easily access any information.
What this means for mobile Web designers and developers, is that first and foremost, we need to approach mobile Web sites as an information-architecture problem, and NOT as a technology problem. Mobile Web sites should be formatted in a way that allows users to easily navigate and make decisions. Users don’t want to dig through the clutter of a traditional Web site to find the tiny link they were looking for.
Companies that merely ensure their existing Web site is viewable on mobile phones, have, for the most part, wasted their time and money. This is primarily because this type of mobile Web site will likely be hard to navigate through, or be terrible looking. All too often, users get frustrated when they can’t find the content they are looking for. This fact is exactly why wireless carrier “decks” exist.
3. Build Unique Mobile Content, or Don’t Bother Building Anything at All.
Mobile is a unique medium and it should be designed with this idea in mind. If you are not willing to rewrite, modify, or create custom mobile content, then don’t bother creating a mobile site in the first place.
This point is best illustrated by an example:
A university could easily mobilize its existing Web content to create a mobile Web site, but do freshman really need to be able to schedule classes from their phone when they are lost in the Quad? The answer should be, obviously, no.
Wouldn’t the university mobile site be more effective if it was limited to custom information that is relevant for on-the-go students—such as mobile maps, a one-click phone number directory and faculty office hours? The answer is yes.
4. Make It Useable. Make It Useable. Make It Useable.
Mobile Web sites MUST always work on every phone. Period.
What this means is that mobile Web designers need to consider multiple screen sizes, as well as multiple technologies. A mobile Web site should dynamically transcode content such as forms, images, videos, ringtones and layouts, so that any user, with any phone, can enjoy a seamless browsing experience. Users should never have to tell a mobile site what kind of phone they have—it should already know.
Consider that for the traditional Web, designers and developers need to account for differences between Internet Explorer, Safari, Firefox, Opera, screen sizes, color depth, Flash versions, and more. Why would mobile be any different?
5. Don’t Forget About Design. Seriously.
Mobile Web surfers are still consumers, and consumers are deeply impacted by design. Don’t believe this? Allow us to introduce you to a fine company called Apple.
Because the concern at the forefront of people’s minds has been technology, brands and agencies often neglect the importance of design in the mobile space. It is almost assumed that because the mobile Web has to work on every mobile device, it can’t also look great. We couldn’t disagree with this mindset more.
When a mobile marketing firm approaches a mobile Web design project, it should design a series of visual layouts for a client that illustrate how the mobile site will look on a variety of different devices. For example, our firm refines a selected visual design concept into a WML layout (old school WAP 1.0), an XHTML-MP (WAP 2.0) layout at several different screen sizes, and (when possible) an iPhone-specific layout. The goal here is to ensure that no matter what phone is viewing the content, it will look its absolute best.
In Summary:
1. Think about the mobile Web in a new way. Get creative.
2. Clear and concise information-architecture specific to mobile is an absolute must.
3. Create compelling mobile content or don’t bother at all.
4. Mobile sites have to work—always. No ifs, ands, or buts.
5. It’s called mobile Web DESIGN. Not mobile Web cram-it-on-the-screen.
About Punchkick Interactive
Punchkick Interactive is America’s first design firm to focus exclusively on full-service mobile marketing. The firm specializes in creating text-message campaigns, mobile games, Flash Lite content, branded mobile Web sites, custom BREW and Java ME applications, iPhone apps, mobile media distribution systems, Bluetooth proximity marketing campaigns, and more. For additional information about mobile marketing visit http://www.punchkickinteractive.com or call (800) 549-4104.
