We are starting the development of an Android and IPhone app and wanted to know if the best practice on developing the UI for both environments.
We have developed the core (functionality) for both the environments as common classes. The core does not have dependency on the UI at all.
Is the best practice to have separate UI code for IPhone and Android or should they be combined together and where required conditionally written?
I would like to understand this as you may have come across situations like this.
Appcelerator has two recommended methods for creating cross-platform UIs - branching and platform-specific commonJS.
In my experience the use of platform-specific commonJS has been the easiest to maintain, although it does require a little extra work up front.
The section on supporting multiple platforms in a single code base in the Titanium 2.0 documentation goes into greater detail on this subject and should be helpful in choosing the path that's right for you.
A good example of creating cross platform UIs is the community app created by Appcelerator's Titans program.
Related
I am currently planning the development of a multiplatform app, and I am not sure wich way to do it fits my requirements best, since all possibilties I could think of failed to satisfy me.
First I want to write an app for android, which should feel like a normal typical android app. So I want to use the standard actionbar and android design look and feel in my other gui elements. After finishing the android app I am planning on developing an ios app, which should have a different design, so i am going to redevelop the gui for this anyway.
But I don´t want to rewrite the other code wich represents the intelligence of the app, independent from the gui. I came up with the following possibilities:
1. Java GUI With native library
Here I abstract all the code of my app in a C++ library (since as far as I know ios supports the usage of c++ libraries too) and develop the gui android typically in java. The library would than have a function to start and would inform the gui about every change via callback functions.
Pro
I can reuse all the code that would be the same on both platforms. I just would implement the gui seperately
The design of the android gui is straightforward as I want it to be. It looks like typical android because it is typical android.
Cons
I dislike the usage of JNI very much. Especially the signature and names of the callback functions (calling java functions from c++) are not checked at compile time and require a lot of manual work. If I rename a function and forget to rework the native part I only notice this mistake at runtime.
2. Build the GUI on the native side
Here I had difficulties finding out what is possible, especially for 2.2
2.1 Use Qt
I have only a few first step experiences with Qt in general but as far as I understood i would have the following pros and cons:
Pro
Reuse most parts of the code for ios and Android. I would than redesign the gui for each platform to make them feel natural. I can´t evaluate how much qt may even assists me at doing that
Cons
I have to copy the android gui by using other qt widgets. This is more effort and I don´t know if one can replicate the android gui elements (like the actionbar) so that the user wouldn´t notice it.
2.2 Using the android framework from the native side
I dont know if this is possible at all, I wasn´t able to find this information. Can I use the class "NativeActivity" and use the android framework to build the gui and use e.g. the actionbar? If this is possible somehow it would have the pros from 1. and maybe wouldn´t have it cons?
Do you have any feedback to my ideas or maybe even new approaches I didn´t think of? How do other multiplatform apps like WhatsApp solve this problem? Do they have redundant code for each platform?
Thank you,
Tobi
I would say that it depends very much on your application requirements. By my opinion, a better solution is to develop a separate application for each platform using recommended SDK's for that platform, and implement in native C++ only the time consuming data processing algorithms.
Application runtime on mobile platforms is not so straightforward as on desktop platforms. You should take into account background and foreground processing, specific application life cycling, accessing system resources such as network, file system, etc. And all these issues do differ on iOS and Android.
Regarding possibilities that you listed.
Qt/QML is ok only in case two requirements are met:
1.1 Your application is a foregroud application without any background operations.
1.2 You purchase a commercial Qt license because only commercial Qt can be submitted to Apple iTunes app store (even GPL apps are under
question).
Using NDK Native Activities on Android with cross-platform C/C++ backend. Android NDK API offers much less API then Android Java SDK, so a lot of things you will have to implement or wrap manually. It is a hard road.
Mixing Java code and C/C++ using JNI gives you more of Android SDK API. But you should remember that an Android activity's life cycle is not somewhat that you're used to deal with when developing on C/C++.
Approach that we are using
We've been developing an application with a huge amount of cross platform functionality that should work on Windows/Linux/Mac OSx/Android/iOS. We're using the approach as follows.
Cross-platform core is written in pure C++.
We have adaptors to GUI interface for each platform.
On desktop we use Qt as it reaches all desktop platforms with minor adapting to each platform.
On iOS the GUI is built using iOS SDK with Objective-C and C++ core is linked as a Framework. Still, we had to patch our core in some way for iOS background requirements and so.
On Android we wrap our C++ core in a background process and build all the GUI using only Android Java SDK. Foreground GUI activities interact with the core via local sockets, so we don't need to bother with activities life cycling in our C++ core. But the adaptor is a litle bit complicated.
Nevertheless, both mobile platforms often require workarounds and adaptations in C++ core which add a number of #ifdef'ed branches in code for each platform.
I want to develop application in android and iOS both.
But i am confuse between native development and development using react and node.js etc.
Please help me to choose (If possible specify reason).
P.S Here cost is not an issue.
If you need high performance and attractive UI and don't want to be blocked by some functionalities that may not br provided by cross platform, I recommend you to use native platform. But if your app doesn't need to be very attractive and doesn't need too much processing, then you can use cross-platform. Actually for many features you need to add plugins if you are building cross platform app and adding number of plugins makes your application slower.
OK, well there isn't much data to go on, but there are several options if you want to write cross platform apps.
There is:
Sencha Touch - HTML and JavaScript
PhoneGap - HTML, JavaScript and CSS
QT - C++ and QML
Appmethod - C++ and Object Pascal
Xamarin - C#
Visual Studio - looks like you can do C# or C++, or Unity for games.
and probably a lot more...
Why would you choose one of these instead of writing in the native language for the platform?
Well, the pros seem to outweigh the cons. If you are targeting several platforms, I would choose one of the options above, simply because you only have to write everything once. If you did it native for each platform, you would write everything twice or maybe three or even four times. Using one of the above tools will be much easier and save you time, and they might be just as seamless and workable as native development.
To simply answer your question, If you would like to be able to write your app once, and be able to manage all future updates by managing only one code base, do cross platform using one of the above tools. The only downside is that you might have to learn a new language (but with a place like Stack Overflow, learning new languages is pretty awesome). It will save you time in the long run.
As we all know, when developing an Android app in native Java, we use activities. I was wondering that, in developing Android apps in Python(with Kivy), does Kivy implements activities for the apps in itself or not? because I don't see any activity implementation on the sample codes.
If it doesn't implement activities, Do we lose performance or any functionality in the application compared to coding in native Java?
Simply put, you can use Activities (starting them using pyjnius), but not really define them, at least, it's not usually the way one work with kivy.
Kivy doesn't adjust its way of working for targetted platform, it uses its own systems, and make them work there. For what i know the advantages of separating Activities on android is just a way to make your code more neatly organized, and doesn't imply performance changes. It can allow you to start your app in various ways (from a share, for example) but you can do that with p4a/buildozer too, by dispatching messages about the intent, if you need to. With kivy, you'll organise your code like you would do for any python project, using modules.
Kivy is a great tool for developing Android Apps. The best advantage of using Kivy is that it is cross platform and the same project can be used to publish apps on mutti-platforms.
However , it has some performance related disadvantages(as do most cross-platform tools like unity , cocos etc). If you're developing only for Android , I'd suggest taking a look into development tools which use Java. This will help create a smaller APK file which in turn helps in better user retention.
I guess you are real loyal fan of Python, but I have to tell you about its advantage and disadvantage.
Advantages
Pure python and its almightiness is in your hand.
Relatively simple to deploy with buildozer without any need to dive too deep into the details of particular platform.
You can run your app on desktop also, so there is no need to install some extra emulators/VMs to get it work
Disadvantages
Not that much information in Internet, even on stackoverflow
Pretty messy documentation
No obvious way to test the application
Not obvious machanisms of placing widgets, especially in built in layouts, which causes situations like: you want place widget in the center of it's parent, but kivy places it anywhere but not where you want it to be.
Official examples are quite ugly, so you may get false vision of how your application could look like.
I created an Android app. While creating one specific app was an interesting challenge, I'm now looking into creating a group of similar apps.
I'd like to create a group of similar Android apps and then move on to creating the same on tablets and iOS... (anything mobile).
I've considered doing so with a product called PhoneGap or doing a web based mobile app. Both of these options seem less than ideal. Doing the Android app I've been frustrated by Java's lack of control and low level constructs. Moving to something like a web based app seems like the exact wrong direction.
C++ is my language of choice. It has the ability to work at a low level, is highly portable across platforms, and has significant support for generic coding which would be useful for generating a group of similar apps. However, the Android documentation suggests to not use C++ unless your goal is porting existing code or dealing with computationally heavy tasks.
I'm leaning towards using C++ anyway, but are there other options I've not considered?
Thanks
You could in theory write your logic in C++ and then have UI layers on top that make use of it. If you are really comfortable with C++ that might be the way to go.
Almost any other parts (networking, UI, animation, etc) are better off being done in the native language of the platform. Use of cross platform solutions always limits you in some way, and usually leads to an application that is not as good as it could be for any platform.
Well, Google's recommendation to not use C++ is based on the following, I believe. C++ is low level, so you can get extra performance out of it if you know what you are doing. Google makes the reasonable assumption that many programmers do not. It is easier for an inexperienced programmer to do harm in C++ then to get a performance boost.
But, if you know what you are doing, it can help you. UI elements on both iOS and Android are implemented in their main language (obj-c, and Java respectively) so there is not a great way around that, but you can write core logic and other functions in C++ and it will be portable between them (iOS can use C++ directly and Android can use it via the Native Development Kit).
There are a few other options available. The one I ended up using is Appcelerator Titanium but please stay away from it. If your project gets complicated or large at all you will hate yourself for choosing it, as I did. Another interesting one that uses C++ instead of Javascript is Marmalade. I haven't used it though, so I can't comment on it.
A non-free solution that I hear good things about is Xamarin, who have ported both environments to C# and a .NET using Mono. However, you still have to write two versions of your code for the UI as far as I can tell.
My work consists of porting an iPad application to Android (so from Objective-C to Java). I've developed in the Android environment, but never in iOS. Currently I am looking for advice -- I'd like to know if is there a way, method, or process which can help me to do this more easily.
At this stage generally the answer is no, but I've got some suggestions that might help.
Use UIWebView/Webkit extensively - baring any HTML5 media (and SVG), there's little porting required when you render HTML. What you render in one, generally, renders well on the other.
If your iOS app is a basic show-this-edit-that style of app, you may find PhoneGap, jQuery Mobile, Titanium or the new Adobe suite a better time investment.
Because Android lacks a consistent device base, which makes developing animation-rich UIs difficult, you might find that there is no 1-1 UI comparison. Instead think about the features you offer, and their underlying data and view models.
You should be able to create a similar UIViewController/Activities structure although the tying logic behind the scenes will be platform specific. Map this out on some paper - it makes a really good what-the-hell-do-i-do-next plan for your UI skeleton.
Prefer an intermediate abstraction between your 'in data' and 'out data' so you can exchange parsers/kits/apis/frameworks without hacking everything to bits.
Where you have custom draw routines and graphics, ensure that you've got filler gradients or colours. Android uses a box model to support the many many screen sizes - iOS only has 4 resolutions to worry about. Recreating the same look might take too much time - contrasting pastel colours are a good placeholder until you can justify making the artwork.
There's not a lot more that can say that hasn't already been said before.
Hope this helps!
Few advices:
You will in most cases need to do redesign of UI as iPad, being tablet PC and having a larger screen as compared with most Android devices. Advice: Check if there is a version of the application dedicated for iPhone as it could be very helpful during redesign stage.
Check if iPad code contains beside Objective-C code also C/C++ code. If there is significant amount of code you might consider using Android NDK which allows C/C++ code to be used together with Java.
If the iPad application was using one of the popular cross platform frameworks (e.g. PhoneGap) that are based on HTML5/CSS/JavaScript combination you might be able to reuse most of the code. Both iPad and Android browser/ui elements responsible for rendering HTML5 are based on same engine (WebKit) and generally generate similar experience. Note: Some frameworks allow custom access to native functionalities which will require rewrite in almost all cases.
Do not try to create exact same UI on Android if it conflicts with user interface guidelines. As you probably know the guidelines are available at: http://developer.android.com/guide/practices/ui_guidelines/index.html
Android users are used to certain interface and they should be getting similar experience as other apps available for Android. Also it might be more than painful to create similar controls for Android that exist on iPad. If there is pressure to make same "look and feel" here is a post that explains how to defend from such pressures: Porting iPhone applications to Android? How to convince them NOT to
Numerous features existing on iPad will not be available on Android (e.g. Android application splash screen using just an image). So analyse the iPad application and decompose it to set of functionalities. Once you have them then you can map them to Android API and start coding.
There are no Objective-C to Java converters at the moment (this might change in the future) but for general feeling what are differences between Objective-C and Java you might want to read "Porting Objective-C to Java" by Theresa Ray of Tensor Information Systems Inc