I'm working in a Java-oriented shop and we're starting to adapt our products to mobile devices now (mainly focusing on smart phones). A separate native app is already in the works for the iPhone, but we would like to make a generic Java/J2ME version for any other devices.
My question is, how feasible is this? And where is the divergence point generally? ie We don't mind if each device has some variation in it's specific Java toolkit and they require separate builds, and thus all we can have is just have some basic framework stuff in common underneath. We're just trying to architect this in such a way that as much of the basic framework can be re-used as possible.
The main target platforms we're looking at are Android, Symbian, and generic Java-enabled mobile devices.
Anyone have any advice, pointers, or good links they can point me at?
The biggest divergence point will be the UI. You will need an entirely seperate UI for an Android App vs. a J2ME app.
If your app does not depend on any hardware components, client side databases, etc. you should be able to reuse any other data model/ backend processing classes.
In my work we have a common Java code base that is used in J2ME, Android and BlackBerry and we have had to address some significant issues:
As Mayra says UI will be huge difference, so you are better off having different UI layers for J2ME and Android.
To make it compile for J2ME you will have to make your common code Java 1.3 compatible. This requires careful design, and nightly builds that compile for each of these platforms.
Because of the above reason we found it a good idea to write your application/game module in Java 1.3 compatible mode.
It also helps if you have a good release management system, because you now have common code for multiple platforms, so, versions, release planning, branching code and its impact on release, all these can become a major headache without careful handling.
If you are planning cross-platform compatibility in modules like C++ and its compatible Java application engine then do yourself a favor and write modules in human understandable format, for example write SaveData class, instead of SaveToRMS in J2ME and SaveFile in Symbian. That way you are encapsulating platform dependent implementation while making it easier for the developer to know whats happening in the class.
Lastly, know that it will take about 6-9 months for a framework like this to mature, so be patient, and good luck.
Well, if you build a web application, all you can do is to do some modifications to adapt it to mobile browsers (if you design it well, there will be only css modifications).
Since you're talking about a shop, it makes totally sense to be online.
I would follow this path.
Related
I'm a python developer with little experience creating android apps in java and want to create an app that will access my university web portal, retrieve some data and show on a view.
So, after researching Kivy, I have a few questions:
1) Which one is easier and faster to develop android apps?
2) Does Kivy have any android feature limitations?
3) And finally, would an android app developed using kivy run as fast as one developed using java?
This is a rather subjective question.
1) Which one its easier and faster to develop android apps?
I think there's a strong argument for kivy, but this doesn't have an objective answer.
2) Does Kivy has limitations to access certain parts of android (like not fully integrated with its api)?
The kivy project includes pyjnius, a tool for accessing java classes through python, and in principle I think this should give arbitrary (edit: on reflection, not arbitrary, but probably not limited in immediately important ways) access to the java apis.
In practice, prebuilt python wrappers are a work in progress, though rapidly improving. The android python library already gives easy access to many things (including but not limited to intents, vibration, accelerometer etc.). Even where there isn't already a python wrapper, it can be very easy to do the necessary work.
Edit: There has recently been great work on Kivy's plyer project, intended to provide a transparent api to platform specific tools so that you can call it once and get the same behaviour on different systems without knowing about the details. It includes useful support for parts of the android api.
3) And finally, an android app developed using kivy would run as fast as one developed using java?
Ultimately the answer is probably no, but the difference is highly unlikely to be important unless you're doing something strongly cpu limited. The task you suggest would not be limited in that way.
To complete inclement's answer, pyjnius indeed allows to access a lot of the android api. But it's not perfect, calling existing classes is not always enough, and an android programmer often need to create code that will be called by android to manage events, there are two ways to do that, both used by the android api.
The first one is interfaces: you need to create a class that implement an existing java interface, pyjnius can do that, you create a python class and declare which java interface it implements, and have a decorator to declare the methods you have to declare.
The second is subclassing, you need to subclass an existing java class and override some methods, and we don't have a way to do that with pyjnius yet, so for these ones, you'd have to create a java class and use it in your program (fortunately you can mix that with kivy/pyjnius, it's just can't be 100% python in that scenario).
So it can be worth a look to the api beforehand, to see if the parts of the android api you have to access requires that.
To get a better understanding of what I'm actually asking let me outline my situation (I think the wording of my question is off, but couldn't think of how to word it better).
I'm currently working in a team of 4 people to develop a basic OCR app. I'm focused on the algorithm side, developing the pre-processing and implementing the OCR. I want as little to do with the app side as possible; as from what I've read so far, it is quite a steep hill to climb and I have enough to do without learning to develop the app from scratch.
So my questions are:
Is it possible to develop my code in a black-box style that I can hand to the app developer and say "Here's a list of functions, go for your life"
Is it possible to do the aforementioned in a way that I can test without the Android emulators?
Is it possible I can do all that without even needing the Android SDK? (given that I can develop my code to deal with specific formats of information. e.g. int[][] for pixel data)
You can certainly write and develop the algorithm without a dependency on the Android SDK, and ship an artifact (whether source code or a JAR) to the Android developers.
However, you will be able to reduce the length of the feedback loop if you at least have an Android test project that takes whatever artifact you ship to the Android developers, and run at least some tests on it - given the number of differences between the Android and Java SE runtimes, it is practically guaranteed that you will run into bugs due to platform differences.
Update: If you write native code or use a native library, I do not think you could easily give a working artifact without using the Android NDK.
As long as your code has no reliance on the Android SDK then certainly you can develop and test without it. Just be certain your code also has no reliance on other APIs (AWT, for example) which are not on the Android platform if Android is your intended target. Finally, be sure that testing is complete within the Android environment, once you're satisfied things are working in general.
I have a Java application that runs on BlackBerry (JDE 4.5). I want to port this application to Android, and be able to maintain the 2 applications simultaneously. I may also want to port this application to other Java platforms (J2ME ?).
I understand that a good part of the code will have to be specific to each platform (UI and other stuff). But I also feel that a lot of the code could (should) be shared (domain related classes).
What is the best way to achieve this, and what are the pitfalls to avoid?
I have been able so far to create a JAR with all my shared classes, that I have been able to integrate into my BlackBerry application (using preverify and rapc). But:
The JAR is a J2SE library. How can I make sure that it will run (or even compile) on BlackBerry, Android or J2ME?
I am also using a JSON library targeting J2ME (https://github.com/upictec/org.json.me/). This library seems to make use of some kind of preprocessing directives (CLDC, see https://github.com/upictec/org.json.me/blob/master/src/main/java/org/json/me/JSONObject.java#L392). How can I use (or convert) this library using the right preprocessing definitions?
This is likely to be difficult:
As you have already identified, the UI code will have to be different for each platform.
There are major differences between Java SE / Android and Java ME-based platforms. For example, ME doesn't have the Collections framework, or the java.io or java.nio stacks.
It is hard to predict from the information you've provided, but there's a fair chance that you'll spend more time fighting the platform dependencies than you are saving by sharing the code-base.
These days, the biggest stumbling block to sharing code this way is that the BlackBerry VM and Android VM both support different versions of the Java language. BlackBerry uses a subset of Java 1.3, Android uses a subset of Java 1.5. (As an aside, neither platform implements a Java VM, both use their own VMs. Java is used as the programming language. Java bytecodes must be transformed to the appropriate native VM format before they can run on the platform.)
The biggest difference you will find as a library implementor is that the BlackBerry lacks the things that were introduced in 1.5, very important things like generics and enums. Even worse, the Collections classes are missing from the BlackBerry. It is unfortunate, but that is the way it has been for a long time now.
This means that to be truly portable you have to write to the lowest-common denominator, which means using (very) old-style classes like Hashtable and Vector, not having generics, rolling your own enums (as in the 1st edition of Effective Java) and so on.
Or you build two libraries, a modern version for Android and a stripped-down version (with just the bare stuff you need) for the BlackBerry.
Hard to say what`s right for you.
Rather than prepackage your shared library, I would consider sharing the library project and having it as a dependency in your mobile applications' build process. That would allow you to share the code base, but have it built by the appropriate builders for your target devices. With a bit of IDE magic and some attention to detail, you should be able to pick up errors before anything is shipped out.
Alternatively, set up your library project to use two separate builders to pick up errors. That would allow cleaner distribution, but you may run into problems trying to convince your IDE to treat the project as being device specific in order to identify problem areas.
It would be likely that you would end up supporting the lowest common denominator device (cough Blackberry), and forgoing the additional facilities of the more extensive Java implementation on Android.
Unfortunately the answer will be one of experimentation. Try it and see what happens.
The article Porting Android code to BlackBerry has some good detail on how to work with code shared between the two platforms.
it will be very difficult to create shared library for blackberry and android.
if you want simple method, create your application as web app.
using
phonegap with jQtouch
I have a DVD cataloging application that I wrote a few years ago with MFC. Records are saved in a sqlite database, so basically it's a CRUD app. UI-wise, it has a tree view on the left, a list view (grid) on the top right, and an HTML view (embedded IE) on the bottom right. Nothing fancy.
I wanted to update the app with more features, but I've been using Java EE for the past couple of years and I realized that I wasn't productive at all with MFC. So I'm thinking maybe I should use something else to boost my productivity. Cross-platform would be a big bonus, but it's not absolutely required.
Here are the options based on my research:
Java / Swing: I can utilize my Java knowledge; great third party libraries (such as Spring for IoC and Hibernate for ORM); cross-platform. Downside is, JRE required for users; Swing seems to be in the "maintanence" mode and it's not getting much attention from Sun.
C++ / Qt: native application;
cross-platform. But I'm new to Qt so
I have to learn it first.
C# / WPF: WPF seems to be the future
of Windows GUI development and I'm
impressed by some WPF sample apps. I
have some experience with C# but I
need learn WPF. Downside is, Windows
only; .NET 3.5 runtime required.
So what would you use if you were in my situation? Thanks in advance for any suggestions.
If you want to learn some new skills while developing this application, then C# / WPF, and LINQ in C# 3.0 is really great if you didn't have it in Java.
If you just want to get on speed, then you already answer your own question, Java / Swing. It is what you are good at.
I'm actually a big C# fan, but since you said that cross-platform would be a huge bonus, I think that Qt might actually be better for that. C# can be cross-platform via Mono, but I've had better results with Qt in that respect. They also have real good documentation in QtAssistant to get you started.
Consider PyQt + Python as well if your productivity is a big issue. Trust me when I say the learning curve for Qt is well worth it, and not as hard as it may seem at first.
Sqlite support is in both the Python standard libraries and the QSql module in Qt if you prefer to use that.
PyQt + Python is a cross-platform option as well, since Python is available for many platforms and Qt's cross-platform to begin with.
The controls you mentioned you used in your application are all available in Qt.
The only other tool apart from raw C++ is Delphi. Period.
With other tools you will have problems in the deployment.
With Delphi you will produce native exes, self-contained. Also, the database connectivity is great.
You never will be dissapointed by lack of controls or 3d party tools, a lot with source code and with free/commercial toolset.
And the compiling times are the fastest in this galaxy ;)
So, if you are serious in provide no-hasle app for your customers, and that customers are not tech-oriented like developers so could be confused because which one of the 4 .NET runtimes install, want minimal support, easy downloads, click-click-install-go, apps that work instanly like Skype,TopStyle (made with Delphi) and others,then Delphi/C++ is are your only option. Seriously. The ONLY options.
If you want a cross-plataform solution, then FreePascal/Lazarus could work if your GUI is minimalist.
In most cases, as long as the scope of the project is reasonably small, and the computational needs are modest, I tend to favor using TCL/Tk. I have not yet learned a gui api in which I'm more productive than tk (not to say that there isn't one, just that I've tried several and found them slower). TCL is not the most wonderful language to program in, to be sure, although there are a number of add-ons that help a lot, specifically [incr tcl] and tcllib.
The reason I choose this instead of other systems, I prefer coding in python, for instance, is because deployment with tcl/tk is close to unbeatable. With Starkit, you end up with a single file double clickable application that requires no installer, and is trivially portable.
Well if you really want a class platform type of application, I would convert it into a web application and host it. That way if one user uploads dvd information or a dvd cover picture another user could take advantage of that information already input into the system.
If your going to develop for the desktop try to make feel like its an application made for that platform by utilizing the OS UI tools. And for windows, pick your 3rd option C# /WPF.
If you have some non UI code in your MFC app that you would like to reuse then consider QT. Otherwise pick whatever you prefer to learn.
Instead of C#/WPF you could give Silverlight a look. You app seems simple enough that it would not take a lot to get up and running. Similar to the demos that are shown off at conferences.
Once you get the basics down it will be fairly easy to add some cool features like animations, movie clips, album art, coverflow like interface etc.
You will be able to target Windows/Mac users and possibly Linux with Moonlight. But I haven't looked at Linux in the past 8 years so I really can't say much about it.
With Eclipse RCP, you get Java, cross-platform development (see Delta Pack), native look (via SWT) and a great framework collection for desktop development (declarative UI, plugin management etc.). You should definitely give that a try.
I went the C++/wxWidgets (but you could do Qt) route a few months back when presented with almost the exact same scenario (upgrade an app with a SQLite db). wxWidgets was fairly easy to pick up, had everything I needed, and was way easier than MFC. The best part was I found a good C++ wrapper for SQLite on CodeProject (e.g., CPPSQLite) and had the whole thing up an running in no time... The project sold me on wxWidgetss, in case you couldn't tell.
I would actually look very closely at something like adobe air. It is cross platform and can be html/javascript based so chances are you won't have a heck of a lot to learn except maybe a javascript library or two. It has the ability to talk to a local datastore or over the interweb to a webservice or RESTFUL service. Development is free with aptana. Check out some of the stuff written in it:
http://www.adobe.com/products/air/showcase/
I was wondering what are the benefits of using anything else but Java for Mobile Application Development.
I do think that yes, Java is the most common language for devices, with two exceptions:
Windows mobile applications, that are frequently built in C++ but that will be built more on the .NET framework in the future.
iPhone applications, that use Cocoa and Objective-C.
Java is the most ubiquitous and for that alone it is your best choice.
You have to use whatever the phone vendor(s) that you intend to support will provide. As most provide Java, but only some provide other things, if you want to support a range of handsets, you probably need to use Java for at least some of them.
Your client (be they internal or external) will need to decide what handsets to support, and you then need to base your decision on supported handsets.
It's not entirely impossible that you'll have to ship versions in different programming languages, which may make code reuse more "challenging". It all depends on your requirements. Nobody on this site can tell you what they are :)
It really depends on what you're trying to do.
Java, whilst ubiqutious does have speed disadvantages. Also it's not "write once, run anywhere" as it is on the desktop space, as different manufactureres, even different devices have different sub-sets of java installed each with differening inclusions of APIs.
Using native code is going to be more efficient, whilst more difficult to port. It provides a more direct representation of the devices capabilities without the sandboxing of a VMs Apis.
Alternatively, you could use a language like C which whilst isn't strictly portable, will have implemenations on many devices with minor tweaks to make, whilst retaining a lot of the speed beenifts of such a language. (OpenC on S60/Symbian), C on Palm etc.
It depends on what you see as the future of the the mobile space. If the iPhone turns out to be as popular as the iPod, then no, Java probably wouldn't be the best choice.
One thing to consider is that at some point there may no longer be such thing as an iPod Nano, perhaps the Touch will be the only iPod available. In that case, every single iPod out would support Apple's iPhone OS and the number of iPhone OS mobile devices would far exceed those of Java.
Five years from now perhaps "Cocoa vs. Android" will be the new Mac vs. PC. In that case, Java could be just as good as Cocoa.
The only reason I can think of is that you wouldn't need a Java runtime on the target device.
Palm, for instance, allows you to code in C and talk directly to the OS routines in ROM. The C code compiles directly to the machine language without needing a runtime.
before one can provide a speculative answer to such a trivial question there are other variables that need be answered. What kind of phone application does one want to develop.
e.g. you can use xhtml for something that does not need to connect to the phones' core features.
and when you need to connect to the phone software or hardware you have can use java,python,c++,windows mobile or the new kid on the block android.
Java is the best if you want to support multiple phones, however J2ME is a limited environment. If you are doing homebrew development then develop for whatever your own phone uses, for commercial development then Java is the most widespread (and there are companies that can port Java to other platforms).
One of the advantages of using native code is your are closer to the hardware, on a mobile phone this means you might be able to take advantage of features which are not exposed to the virtual machine upon which your Java application is running, the promise of Android is that everything is a lot more exposed that it is with a typical Java Mobile implementation
Best is to go to nokia, apple microsoft or google web sites or whaterver and see what developer tools and resources are available and choose the one you want to develop for all of them are very good as good mobile app developers can help increase their market share.
Depends on what Application you are trying to write.
If its a simple service / data provider I would use HTML and CSS via a framework like
jqTouch, jQuery Mobile, or http://www.sencha.com/ as these will run on mostsmart phones and you can package them into a binary app using something like http://www.phonegap.com/ this will allow for sliding, GPS, local file storage using HTML5
If you need to a database, motion sensing, bluetooth, game type application then you could look at
http://monotouch.net/
http://monodroid.net/
That lets you write c# .net code and deploy onto any platform do you should be covered for windows mobile, android and iPhone.
There is also http://rhomobile.com/ that lets you write applications for all mobile platforms using Ruby.