Native Development on iOS and Android Jan Kroon, Real Thinks B.V. @ mdevcon March 10, 2012
My Timeline Researcher Project Manager CTO CEO CEO Business Development Entrepreneur Universität BernMathematics & Physics Phd Computer Science Management Listener Speaker
IMHO App Generators suck ...If your goal is to create an amazing App • You want to use the latest and the greatest features • You want to test and tune performance • You want your App to feel natural to usersSo you develop a native App, and if you want to reach aworld market you develop native Apps on multipleplatforms!
Your body is the controllercompass / gyroscope accellerometer
iOS and Android Xcode ~ Eclipse ObjC ~ Java iOS SDK ~ Android SDK project ~ ManifestXIB ﬁles ~ XML User Interface ﬁles ViewControllers ~ ActivitiesTableViewController ~ List Activity? Instruments ~ .... ... Jan ~ Hugo
Interesting Areas• User Navigation• Screens• Multi-tasking• Inter App Communication• Sensors• Apple / Google Services• Testing on Devices
NavigationWays to control an App:• push hard buttons• tap soft buttons, sliders, switches, ...• gestures on content, e.g. swipe, pinch• movements, e.g. shake to undo• speech
How your brain works• Cortex makes a model of the world on six abstraction levels, and constantly predicts the next input of your senses. Jeff Hawkins: On Intelligence• That’s why real world metaphores like buttons, tabs, sliders etc. are useful• That’s why consistency is important, the real world is pretty consistent• That’s why animations are valuable, if you touch real world objects they often move.
Navigation in iOS and Android• Apple has a tradition of writing excellent Human Interface Guidelines, controls all software and hardware, and bundles Apps that give a good example. (Contacts - TableView / NavigationBar, Music - TabBar, Weather - FlipSideView).• Google has a hard time. It controls only part of the software stack. Hardware manufacturers often add their own presentation layer and bundle their own Apps. And even worse carriers can determine to switch off certain capabilities or refuse bundled Apps in favor of their own Apps.
Android phonesHTC Sense Samsung TouchWiz Google Holo
Differences iOS and Android• Android users are used to use hard buttons for “home”, “back” and “menu”. iPhone users expect a navigation bar with a title and a “back button” or a “tab bar” and only use a hard button for quiting an App.• In Ice Cream Sandwich (Android 4.0) all hard buttons are replaced with three standard soft buttons “back”, “home” and “task manager”.• Apple distinguishes between a NavBar, TabBar and a ToolBar. Google introduced an Action Bar in Ice Cream Sandwich, that is a mix between a NavBar and a ToolBar?
FigureRunning Apps status bar action bar nav bar tool bar
Screens• Older iOS devices have a screen of 320 x 480 or 1024 x 768 pixels. New iOS devices have a Retina display of 640 x 960 or 2048 x1536 pixels.• On Android you may stumble upon any size screen that was ever manufactured. That makes it very difﬁcult to create pixel perfect designs. It also explains why the “menu” button is very popular.
Multi-tasking• FigureRunning App should continue working, also when a phone call is received or user chooses another song in the Music App.• On iOS policed multi-tasking is possible since version 4, but only in special cases, e.g. navigation, playing music, and task completion.• In Android unrestricted multi-tasking has always been available. This makes a developer’s life easy, but comes with a performance cost.
Inter App Communication• Share FigureRuns on Twitter and Facebook or send them attached to an email.• In iOS it is possible to do all that, without leaving the App. (URL scheme or make own UTI for attachment)• In Android it is necessary and normal to leave the App and switch to Twitter App to send a Tweet or Facebook App to put a post on a friend’s wall.
Sensors• We encountered no problems at all. It was even possible to use each other’s algorithms.• It seems that the closer you come to the hardware, the more similar iOS devices and Android devices behave.
Apple / Google Services App Store ~ Android Market Google Play In App Purchasing ~ In App Billing iAd ~ AdMobPush Notiﬁcations ~ Android Cloud to Device Messaging iCloud ~ No Google equivalent? Game Center ~ No Google equivalent?
Testing on Devices• We are testing the Android App with a big group of volonteers from all over the world.• Unfortunately many crashes only happen on speciﬁc phones.• It is often impossible to reproduce the problems on our own devices. So we are down to studying crash logs.• Clearly testing on iOS devices is a breeze compared to testing on Android devices, due to the fragmentation of the platform.
Conclusions• Android devices differ from iOS devices mainly in user experience and the software. The closer you get to network, sensors or processors the more similar the two platforms are.• Android development differs from iOS development in that Android development tools are not as advanced and integrated as Xcode.• It is practically impossible to write an App that will run ﬂawless on all existing Android devices.
Recommendations• Make separate User Interaction Designs for iOS and Android versions.• Let a “native developer” translate your App.• Aim at a few popular Android phones, make sure your artwork looks great on those phones and test performance of your App on those phones. Don’t worry about the rest. Develop More Amazing Apps!
Similarities• An App consists of a bundle with code ﬁles and resource ﬁles (data, texts, images, sounds)• The App is created with a set of programming tools, named Integrated Development Environment (IDE). Most Android developers use Eclipse, all iOS Developers use Xcode. Typical tools are editors, syntax checker, static analyzer, simulators, debuggers, etc.• The code is written in an Object Oriënted programming language (Android developers write Java code, iOS developers write ObjC code) --- Objects, Messages, Inheritance, ..• A developer can use Frameworks that are made available by either Google (for Android) or Apple (for iOS). A Framework contains ready-made objects that a developer can integrate and use in the App. There are frameworks for WebViews, MapViews, ListViews, Sending Email or Tweets, Showing Movies, ...• The App is executed as a process in a Run Time Environment (RTE), that is logically separated (sandboxed) from all other running processes. In Android this RTE is named Dalvik, a Java Virtual Machine. In iOS it is the iOS run time.• ...
Differences iOS is much more consistent in it’s animations than Android: • lifting one screen and taking another screen from underneath the ﬁrst screen and place it on top (like if you take a book from within a pile of books, and place it on top of the pile) is used for switching between Apps • a screen sliding in view from the right or left is used for moving through a hierarchy (as the result of a tap) or to view a collection (as a result of a swipe) • a screen that slides up and down and partially covers the original screen is the way to display utility panels • fading in and out of a screen, or ﬂipping the screen is used for switching beteen screens within the App. Android has only recently begun to catch up with Apple in paying more attention to design and typography. Apple is fanatical about human interface guidelines. E.g. they teach never to put “Yes” or “No” buttons in an alert, because this forces users to read the question and may cause problems if they don’t. Putting “Cancel” and “Delete” in the buttons is a superior approach. This attention to detail makes the difference between “Good” and “Great”.The run loop in iOS RTE juggles with Apps, your App is either running in the forground, running in thebackground or suspended in the background. The run loop in Dalvik juggles with activities, i.e. the screens (andwhat happens behind the screens) of your App or other running Apps. Android doesn’t show clearlywhether the next screen is from your own App or another App. I am often clueless about which App I am usingon Android, you get screens from Mail, Browser, Maps etc. without ever having started those Apps!