Native vs hybrid: The Case for Native
•Download as PPTX, PDF•
0 likes•138 views
An attempt at making a case for which is better, native or hybrid development for mobile applications.
Recommended
More Related Content
Similar to Native vs hybrid: The Case for Native
Similar to Native vs hybrid: The Case for Native (20)
Recently uploaded
Recently uploaded (20)
Native vs hybrid: The Case for Native
- 1. The Case for Native jeffgodwyll.com
- 2. Scenarios for the native approach... Existing native skills
- 3. Scenarios for the native approach... A single mobile OS
- 4. Scenarios for the native approach... Single native functionality
- 5. Scenarios for the native approach... Rich UI requirements
- 6. The goodies... Performance aka #perfmatters
- 8. The goodies... Access to all/most platform features
- 9. The goodies... Large community support
- 10. Native Android = Java + XML
- 11. Creating the layout <RelativeLayout tools:context=".MainActivity"> <ListView .... /> <EditText …./> <Button …."/> </RelativeLayout>
- 12. Example main activity public class MainActivity extends Activity { @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); } @Override public boolean onCreateOptionsMenu(Menu menu) { // Inflate the menu; this adds items to the action bar if it is present. getMenuInflater().inflate(R.menu.main, menu); return true;
- 13. Let’s build a simple todo app https://goo.gl/Klvdk7
- 14. Helpful links Must have android libs: goo.gl/SujEfn Android documentation: developer.android.com Android on StackOverflow: stackoverflow.com/questions/tagged/android
Editor's Notes
- In some cases, an organization will aim to release a mobile application to a limited target audience—one that is known to use a single mobile OS. For example, consider a scenario in which an internal application is distributed within an org. In this case, achieving multiplatform coverage might not be a priority and, as developing a single native application requires a limited set of skills and tools, this approach can make much sense
- Accessing device specific API’s. Some applications are built around a single functionality. Take Skype, for example: Voice over Internet Protocol (VoIP) and access to the user’s contacts are key elements of the app and, given available technologies today, can only be developed natively. For such applications, web languages are simply not yet sufficiently evolved and are far from capable of achieving the desired functionality. In Javascript you have a lot less control on connection and the OS in general. For example: when you are using VOIP and the phone goes on standby, you will lose connection because on iOS cannot run on the background with Cordova. Android has some ways of running in the background but you will have to experiment if this works when you are using VOIP.
- More familiar UI / look and feel, For game-like applications that require a rich UI that provides real-time responsiveness, web technologies do not yet provide an adequate solution. For applications with such requirements, developers are still better off taking the native approach.
- Colt, need I say more :D
- stack, developer.android,
- stackoverflow, developer.android,
- We’ll use a very popular tutorial from one of codepath’s android guides, these guys are awesome and have created lots of content for budding and experienced android devs alike