We are talking with Mike Liu, the creator of “My Stocks Portfolio & Widget,” about his observations on the Android app market, his success recipe and expectations.
Telerik: What got you into Android development?
Mike: I developed apps on Windows Phone (WP) for a few years as a hobby and Android/iOS were platforms I've always wanted to look into but never had time. I quit my job earlier this year to pursue some start-up ventures, which freed up time to build apps on Android and iOS. I like Android for its openness and certification process, allowing me to push out updates in a matter of hours, which really helps when fixing bugs and implementing small feature requests based on user feedback. Also being from a .Net background, Java was quick to pick up, so Android was an easy choice.
Telerik: Judging from the rating and reviews of "My Stocks Portfolio,"' people are enjoying the app. What do you think contributed most to the app’s success? Based on your users' feedback, what is it that they liked most in the app?
Mike: For "My Stocks Portfolio" (MSP), I reached out to past users of the WP version of the app who switched to Android and asked them what they found lacking in existing Stock apps on Android, what feature requests went ignored, and tried to convert them one at a time to using MSP. Stock apps on Android are a crowded category and it's hard to get traction, so it helped to listen to the feedback of my initial users, implement their suggestions, and make them advocates of the app.
What users have told me they liked most about the app is its simplicity of use (it doesn't take many taps to get at the important information such as viewing gains/losses of your portfolio) and UX. I think having a great user experience will make the app stand out, so it was important to implement features such as interactive charts.
Telerik: How did Telerik UI for Android help you achieving the desired result? In what way did the product improve your development process?
Mike: In the initial release of the app I wanted to have interactive charts that had pinch-zoom, panning, and trackball support. This would have taken quite a while to implement myself and to work through all the bugs. By using the Telerik native solutions, I was able to integrate the charting controls which met my business requirements and complete the feature quickly, allowing me to focus on adding other features to the app.
Since the Telerik controls are used by many devs, I knew that it was well tested and would continuously get improved on. I could submit tickets for issues, freeing up dev cycles for me to work on other things. Also having used Telerik UI for WP, I found Telerik Android APIs to be very similar between the two platforms and it was easy to look at the WP code as reference when porting over the charting features.
Telerik: Do you plan to offer the app on the other two native mobile platforms--iOS and Windows? How do you plan to achieve that--create a separate app for each platform or use a cross-compile tool like Xamarin or NativeScript?
Mike: The app is also on WP (http://peeksoft.co/apps/mystocks). I plan to release an iOS version, probably using the new Swift language.
I've prototyped apps using Xamarin and html/js solutions such as PhoneGap/Sencha Touch/Kendo UI. They can reduce dev time, increase code reuse (especially if you use some common pattern like MVVM and keep all the business logic shared), and might work depending on the type of app you're building. I built a cross platform prototype of MSP on Android using Mono, but in the end Mono on Android didn't meet my app's startup time and apk size requirements so I re-wrote the app natively.
I think native (Java) apps still offer the best start-up performance, in-app performance, smallest apk sizes, and best optimization tools (i.e. ProGuard), though the first three will become less of an issue as mobile hardware gets better and some cross platform solutions like Xamarin offer comparable in-app performance. It all depends on whether you think the compromises will affect your user experience and whether you're okay with that.
Another reason I went native is because Android (and similarly iOS) has a huge dev community with lots of code snippets and third party libraries which are easier to integrate natively than trying to make them work in a cross platform framework. In cross-platform frameworks you usually have to rewrite these, look for similar ones or create native wrappers.
Telerik: What do you think about the emerging cross-compile tools for mobile development? Are they something you are going to consider? How do you think native mobile development will evolve next couple of years?
Mike: I'm always on the lookout for promising cross platform frameworks and I think as mobile hardware gets better, the difference in performance between pure native apps and cross platform compiled apps will get smaller. I think native apps will always have the best support for native libraries and the latest hardware / API features (and this probably won't change unless the big companies decided to co-operate), whereas working with a cross platform framework you sometimes have to deal with issues that may be a result of the extra abstraction layer.
On the other hand, having a cross platform app with lots of code re-use is every developer's dream--having to only write once and target all platforms at once. I think there are several cross-platform solutions today that work perfectly fine for most apps-- it all depends on whether you have to make any compromises for your app and whether you're okay with them.
Telerik: Thank you Mike for this interview.
Subscribe to be the first to get our expert-written articles and tutorials for developers!