Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Coming from J2ME programming are there any similarities that would make it easy to adapt to Android API. Or is Android API completely different from the J2ME way of programming mobile apps.
Actually the Android API is much more powerful than the J2ME.
It is much easier to create an application for the Android.
Using the J2ME you are limited to simple forms due to the absent of swing-like libraries (though now there exists a library called LWUIT, avoiding the need to recreate from scratch a swing-like library).
In Android you will be able to create complex form very quickly, and software package for the android SDK is easy to install (while in J2ME you have to install the wireless development toolkit from sun, or install one of Nokia's, Samsung's or SonyEricsson's... it gets a bit confusing sometimes).
The things I had to change when switching from j2me to android were:
1/ The font and graphics class is easier to use on j2me. The API is more thorough on Android, but also more complicated.
2/ If you are used to the database storage of j2me (RecordStore), well you can forget it in Android. You will have to use a SQL-like databased, so be prepared to rethink your data model.
I've also found the path from Java ME to Android to be pretty simple. Here are a few things I've noticed:
There is ONE ui draw thread in Android. You have to be aware of the difference between calling postInvalidate and invalidate on Views to force them to update.
The actual bit-wise graphic manipulation is very similar. I was able to port large amounts of custom J2ME draw code by writing a few shims for drawRect and drawImage.
Android's UI library is much more extensive, much less useless, and much more complicated than Java ME's
Threadwise, you have to be much more careful about thread saftey with Android. In Java ME you can get away with not making methods synchronous or variables volatile most of the time. Not so in Android.
I will say, on the whole, that Android's UI library fails a critical test. I call this the "roll my own" test.
Your UI library fails this test if it takes me longer to complete a detailed task task (say, changing the background on one individual menu item) than it would take me two write my own Menu from scratch. Android fails the "roll your own" test by a factor of 3 or 4. In fact, if you look, the majority of the questions on this website are "How do I make the Android UI toolkit do my bidding?" questions.
Android is an amazing platform and it has been worth every frustrating moment I've sunk into it. It is, however, a young platform, and needs some serious work in times to come.
A good start would be to watch the Android architecture videos and look at some of the documentation.
http://www.youtube.com/view_play_list?p=586D322B5E2764CF
http://code.google.com/android/what-is-android.html
Google is very good about documenting. From what I've heard Android very very similar to J2ME in its goals. It may be slightly different in programming style and structure but if you have J2ME experience you should be more then ready to move on to Android.
Good Luck!!!
Well, you may not actually need to adapt.
There is a good chance that a J2ME stack will become available for Android before long since Android is not supposed to become as restrictive of third-party runtimes as the iPhone.
I know one guy who has been working on just that:
http://justanapplication.wordpress.com/
Now, of course, that doesn't mean you shouldn't have a look at the Android APIs and application lifecycle.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I have been using the flash pro for 6 years now, and I find it very easy to create any kind of application and game (except 3D ones). The flash pro says that is can compile cross platform natively in Android (and iOs too), so am in a dilemma (or trilemma), should I use:
1. The flash pro IDE which I know very good
2. Should I learn Eclipse which I hear is ideal for Android apps or
3. Should I make the app with HTML5, jquery mobile, etc and compile it with PhoneGap?
The app I was to develop is quite simple, it has a list of POIs, categories, (from online database) and it shows them on map (flash pro may have to use stageview for that), so the graphic processing required should be minimal. It may also cache some POIs when downloaded on phone.
Please answer the question in relation to:
- Speed/responsiveness of the app
- How much "native"/professional the app will be
- Feature-wise, would all the features be there
- Debugging
Thank you,
Panos
You are always going to be able to get the best results with the most native approach (eclipse) as long as you can handle the IDE and language. You have a good deal of experience with flash and if you don't have much or any with Java you may have trouble getting into using Java.
Here's a simple breakdown though:
Flash:
Great for apps that serve as a web frontend.
Supports most common android features.
Doing anything heavy in processing or too custom tends to get bad performance.
You are abstracted from what the app is really doing and therefore have less control.
Java:
You are using the native language and therefore can use android to it's fullest extent.
You will find plenty of help for any problem you run into and it's much easier to debug more complicated apps.
Better performance in most app usages, especially for more complex apps.
Not cross-platform though you don't seem to care about that.
PhoneGap:
I have no experience for this but I would assume it's similar to the Flash approach.
Probably really good for Web Frontends.
The choice is really just dependent on what you feel would best suit your current knowledge and goals for the app.
I would strongly recommend just learning Java and using Eclipse as it will always be as good and responsive as you can design it.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
:) When you write a iOS App, in order to use the UI like buttons. you have to write it in Objective-C. (Java on Android). I was wondering if anyone had any thoughts on the technical reasoning behind this. Why they might of done this. As you can write apps in C++ on iOS so I've never fully worked out why they didn't expose a way of making the UI in that. (Ignoring the fact that this is how they did it on the Mac).
Note: I know you can write apps in c++ for Android but the question is more why is the main UI i.e buttons etc forced to be written in a dynamic language for these platforms, why not expose access to it thorough C++ without having to write a crude wrapper or binding layer yourself.
I'm guessing that when the original framework engineers were working on their respective operating systems, cross-platform desires like UI support in a different language like C++ was at the bottom of their concerns. You'll have to realize that when deadlines loom, all of the features are prioritized only what is considered most important is made to work. Everything else is a consequence of that.
In the case of iOS, Objective-C is the language of choice for the OS that Apple uses. All of the MacOS app developers were writing in Objective-C so their developer based was in familiar territory.
In the case of Android, Java was already a popular language, with existing open source tooling and libraries (Eclipse IDE, Apache Harmony), so presumably they decided to use Java as the first class language for app development with apps running in a VM as a consequence. Alternatively the decision may have been VM first for the sandboxing of apps and Java was picked as the language for app developers. Or some other reason.
In either case any attempt to add in additional languages now that both are in the hands of customers means design decisions and trade offs along with a host of other questions like: how to add it in without breaking existing APIs, how to support it along with new features, how to test, etc. etc.
As you see more and more software, you'll realize that lots of stuff is just arbitrary or made sense at the moment of when it was designed.
iOS does expose a C API for drawing UI components; it's called Core Graphics.
Because the view itself is written in Objective-C, or Java, respectively. When in Rome, do as the Romans do.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
We would like to develop an application that runs on both iOS and Android. We cannot come to a decision however whether it is better to first create the application on one platform and once we are satisfied, replicate it on the other, or finalize UX decisions in the beginning and develop the platforms in parallel.
The application is simple and we have the resources for developing it. It is just a question of whether to develop the platforms sequentially or in parallel and if sequentially, then which platform to start with (again assuming resource allocation is not an issue).
As for me, developing both versions at the same time always means more time. You can have your design, workflow, architecture perfectly defined, but there'll always be changes during the development (not to say if there's an external client making decisions). If you're developing for both platforms in parallel, chances are that you will implement those changes twice, while if you first finish your app in one platform, you shouldn't find more unexpected surprises in the second one.
The next question then would be: which platform should I start from? I choose Android for two main reasons:
It's a lot easier to refactor code / project structure (at least for me) in eclipse than xcode.
I design the user interface keeping in mind the largest resolution (Android xxhdpi), then I cut my final png assets once using android resources naming conventions (which is more restrictive than ios), and run automated tasks for the rest of densities (xhdpi, hdpi, mdpi, iOS and iOS#2x)
Regarding cross-platform frameworks (i.e. phonegap), imho the effort will never be divided by two, and the user experience will never be close to the experience reached with a native application. Unless your app is extremely simple, I'd highly discourage these kind of frameworks.
We had the very same debate when we started developing the app we're working on.
First, I should say that if your app is simple enough (doesn't have too many heavy animations, 3D, etc), you might want to look at some multi-platform solutions:
http://mobiledevices.about.com/od/mobileappbasics/tp/Top-5-Tools-Multi-Platform-Mobile-App-Development.htm
I personally feel that multi-platform solutions are still too far behind native apps, but it might be suitable for some apps.
In the end, we decided to develop the infrastructure of our app on one platform (Android), and then start building the app on the other platform (iOS), once the strength and performance of the Android app's infrastructure was proven. When we developed the iOS app, the infrastructure from the Android app was copied.
There are several advantages to this:
After you finish designing the architecture of the app, you test it once on one platform. If the architecture failed to hold up, you don't need to start 2 projects from scratch - only one.
Once you develop the app once, at least the infrastructure, you've already gone through all the major hurdles of development. This will allow you to complete the development of the other platform with relative ease and speed.
Developing 2 projects simultaneously will probably result in significant differences in the way the code works in both platforms. While there will always be some differences, due to the large differences between the platforms, it's better to minimize the difference between the way the apps operate - this will make maintaining the apps in the future much easier. (Solutions to problems will be essentially the same - iOS & Android teams can copy their solutions off each other).
Developing simultaneously will probably be quicker, but riskier, and will cost more time when you need to maintain your app.
Hope this helps your decision making :)
That depends strongly how you develop the app. If you develop on multi-plattform, I would suggest to us a framework like phonegap: http://phonegap.com/ . With this approach your question disappears and you saved half of the effort.
If all resources are available and requirements are clear then you should go for parallel development because its not best practice to make any resource sit idle.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed last month.
Improve this question
So I have been working on a medium sized enterprise app for the iPhone that I may have to port to Android. I wrote the app using the native iOS SDK without any care for portability. I initially cringed at having to re-write the entire app in Java and maintaining two code bases, so I looked into some of the cross platform options.
I wrote a simple "hello world" in two cross platform applications and one using the native SDK just to get a feel for the performance and stability of each platform. This was by no means a completely exhaustive experiment, just quick and dirty test. I was surprised to find that PhoneGap and Appcelerator’s Titanium had a very noticeable startup time just to display "hello world". Additionally, both PhoneGap and Titanium crashed if I closed the application and then reopened it in rapid succession (30-40 rapid iterations). The Native app on the other had never had any problems.
Initially I thought I could live with the slower startup times because of the promise of one code base to rule them all. Then I ran into the following potential roadblocks:
Debugging support seems limited.
According to the phone gap wiki it is recommended that you debug (1) on your desktop (2) using a remote web inspector (3) printf debugging [are you kidding?] or (4) using weinre
Debugging for Titanium is slightly better but still lacks on device debugging support. There is an open request for on device debugging that is a year old so it may get fixed in the future.
Debugging may not be a problem on small projects with a few developers but it quickly becomes very important the larger the project gets and as more developers work on the same code base.
You still have to adjust the UI for each device.
This may or may not be a concern for some people but I would like our app to look like a native app and follow each platform's human interface guidelines. So I will still have duplicate code at the UI layer.
At this point given the fact that I have to have separate UI code for each device and the on-device debugging options are not as rich as a native app I don't see the savings that a cross platform development framework will give. I am thinking that the best route to go is to re-write my models in C and then I can share that code between Android (using the NDK) and iOS with each device having is own native UI.
So my question is, what experiences with cross platform mobile frameworks does anyone have? Are my fears of limited debugging and duplicated UI code unfounded? Please keep in mind I want to have an application that looks like a native app for each platform.
For those of you that have used a cross platform framework how large was the project? What problems did you run into? Would you use the framework again?
-Shane
I have used appcelerators titanium quite a bit. My general feeling is that the IOS section is very good but the android is still lacking, particularly in error messages, debugging isn't so bad as all you have to do is add a few print outs, but the issue being that 99% of the errors on android will be something like app crashed with nullPointerException with no hint as to where because its coming from the underlying java, it can be tricky to say the least.
However I will say the UI stuff is not an issue, titanium takes control of automatically scaling the apps to different device screens (when a setting is turned on - should look into this came in with 1.7). So generally the only issues you will have is device specific things, like having a right nav button in IOS, there is no android equivalent so you have to code something special for that, which is understandable given there 2 different platforms.
I'm not sure what I would do given the IOS is already fully developed, people generally go to this to avoid a learning curve for both platforms and to save time with keeping the same code base, Not sure how much benefit you will get out of this. Appcelerator is good but there are bugs in controls, it will be slower and it will take time to learn but it does have benefits.
I personally wouldn't use phonegap as I don't like the idea of it basically being a webview wrapper and I've had enough browser based issues on desktops to last me a lifetime.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I am trying to break into a bit of development and have been advised Ruby is quite an easy / powerful language to get started on.
My main hope for learning a programming language was to break into mobile development. I have heard Ruby can be used for Android development with the right 'kit' but is this a practical language to use for this or will it end up being a more long winded approach than just learning Java from the get go?
I recently read about Ruboto. You should check it out too!
Maybe you should be looking at http://rhomobile.com/?
Almost all the documentation on android development is focused on Java, and eclipse. While I'm not a big fan of Eclipse as an IDE (bloat); it is what the lot use, so it is what I use.
Where you'll find hardship with ruby is when you have to do something that is atypical.. something that is purely android. It will save you time in the beginning, however as with all high level languages, it will end up costing you more when you need to get "dirty"... The net result will be the same.
I program ruby/rails during my day job and android for my "unpaid". Both are good languages, but there are strings attached with any language.
Keep in mind also that the Android platform is Java supported.. In this you know if there are new features in OS 5..6..n then you can be sure there is a way to access them in Java. Ruby might be quick to integrate them, but then it depends on the developers (us) of Ruby. Also keep in mind that on some older devices 1.x..2.x there may be things that run slow when passed through ruby. (I don't know how it's interpreter works)..
Last note. If you learn Ruby for android, and you apply for a job programming Android, I'm betting they will expect Eclipse/Java not xxx/Ruby
Not very sure of Ruby , but you can surely use JRuby http://code.google.com/p/jruby-for-android/
If your goal is to learn mobile development on Android, I would highly suggest sticking with Java. The Android SDK is Java based, and the majority of documentation and examples (including the official docs) you find will be in Java.
While Ruby is a powerful language, it is primarily used for web development. You may have a difficult time finding documentation, and support when you're not using standard Android language.
It appears that Google mainly supports using Java with Eclipse. While you probably could do it with Ruby, I think your best bet is to just use Java and Eclipse.