we are planning to build a web based client side application framework. The main focus is to write native looking webapps using Java and compile them for your target platform.
Our planned target platforms would be the iPhone and Android (on top of PhoneGap), Backberry and Palm WebOS.
Our goal is to create a decent framework and that's what this post is about. We want to know what developers would expect of such a framework and on what topics are more important than others. We also want to know if it would be more important to provide a UI-framework which really feels like a native app on the target platform (e.g. scrolling behavior) or to provide some decent APIs to use HTML5 and PhoneGap features, store and manipulate data etc.
What would you, as developers, really like to see in that kind of a framework? After all, you're the ones that will (hopefully some day) be using it. And most important: Would you use it?
I would like a good GWT framework for mobile plateforms (at least iPhone and android), with a native feel UI (ie : smooth scroll, fast click), and UI customization by CSS.
I would pay for that !!
Make the setup and default behaviors of components work right out of the box -- give them either a builder pattern so that the component is ready to be useful in one line, or constructors that contain sufficient amount of parameters to create a well-formed object.
Along these lines, every GUI component should have an adapter to take a variety of model based data structures. Pass it along, no-fuss, no-muss, and absolutely no boxing/unboxing.
the bad thing about the webkit based mobile frameworks is they are not as smooth and fast as other applications. This is where all they stack. I would recommend you to write a JAVA Dalvik framework, which is easy to extend an use with a nice error handling and strong UI. It should definetly have it's own plugin pattern so the community can extend it if you are planning to go open source
My personal favourite would be something that would allow me to develop using the Widget Standard http://www.w3.org/TR/widgets/ and then publish to app stores by wrapping the widget into a webview or similar. Opera Mobile, Samsung Bada, Symbian and now Android support the platform already.. http://labs.opera.com/news/2010/12/22/
This would include a barebones JS framework that could be Closure Compiled smaller, using only the methods/ parts of the framework I really used, to keep the size minimal.
Um... if it's going to be
platform-specific and client side
Our approach is to be as device platform neutral as possible.
As said before: Our goal is to write an application in Java and to compile it then for a specific target platform. It should also be possible to compile the same application without any (or at least as few as possible) changes in your Java-Code for all our supported platforms.
We choose to use "the web" as our runtime because almost all mobile platforms provide some kind of web environment on which we could deploy our apps.
Related
My team is looking for something similar to storybook for native mobile development. We're building a design system and need to develop isolated and encapsulated components independently. Any idea if there is a way to enable swift and java on storybook? Or maybe another tool that serves this purpose?
Found this after a quick online search. Xcode contains Liveness since Xcode 7 or something. It basically enables you to have Interface Builder render your custom views. I always use it in my Storyboards. It saves time on making adjustments. Given that all UI related classes are in a separate framework.
SwiftUI has this ability with it's live view option.
I want to develop a navigation app like "Find my Car" or something. For the navigation and the map i want to use the google maps api.
Now i must decide, which language i want to use. Java vs. HTML5.
I'm more familiar with Java, but in the Google Maps API documentation, it would be easier to develop with HTML5, is it?
The application must run on a android phone. So what is better to use: Java, which i'm more familiar, or with HTML5, which (i think) is easier to use in combination with Google Maps.
Hope you can help me, i must decide me in approximately one hour.
Generally, I would not say that the answer is always Java. It actually depends on your needs, like always.
The great thing when you use HTML5 (you could try PhoneGap: http://phonegap.com/) is that it will work on multiple different systems, whereas a native Android app won't.
On the other hand, in a native App, you will be able to access to the whole Android API, and it will be more powerful as well.
As a conclusion, if you need a powerful app processing images in real time, you want a native application. But if you want something simple that could easily be rendered in HTML5 and you potentially will create the same application on a different system (say, IOS), then HTML5 will make you earn precious time.
And in the case where there is not a clear "good" way to follow, simply choose the one in which you are more comfortable: as long as you can create an application that answer your needs, it will be the most productive way.
And always keep in mind that it is possible to include a "WebView" in an Android native app, which means that you can have best of both worlds.
In your very situation, it seems that Android already has some nice features for using Maps (most probably better than the HTML5 version). That might help your decision.
if you're developing an app (not game) in Android the answer is always Java! Always!
and implementing maps in Android in its native Java is as simple as 1.2.3 https://developers.google.com/maps/documentation/android/
Language, IDE, platform ... everything is tool. What will you use depend on the needs of your application. I work with both techniques. When you'll develop an application that uses many resources linked to hardware (eg accelerometer, gps...), it is advisable that you use a native language, it saves battery and you has the maximum advantage of the device, gaining in performance.
Now if you'll develop an application that uses few hardware resources, the most interesting solution is HTML5 (example: PhoneGap, SenchaTouch, Titanium, etc..).
In my years of experience, before deciding how to develop I wonder what I will develop, so as to see which one best meets my need!
I have written some basic applications using J2Me and felt that getting things done in terms of UI/UX were a night mare especially with blackberry OS 5. I then started playing around with Webworks and found it to be better and faster however i keep getting told that it is better to stick with J2ME. Which one is a better choice? Is one limited in features than the other? What will RIM support for the long term future?
This is a decision to be made for each application.
How well do you know HTML, Javascript, and CSS? How much device integration do you need? How graphics intensive will the application be?
HTML et al have a much lower learning curve than J2ME and the RIM APIs. You are missing some of the more functionality that integrates deep into the phones abilities. But you have a distinct advantage in that anything that you find missing in the Webworks libraries, you can write as Javascript extension in Java.
Webworks itself is limited to the blackberry platform, but HTML, Javascript, and CSS are practically universal. It's simple to turn the application into something that will work in a web browser. Just take out Javascript calls to any blackberry.* apis (or wrap their use in blocks like if (blackberry) {), and redirect anything in an XMLHTTPRequest to be proxied through something on the local server. I'm doing it this way for a Playbook app I'm working on. It's nice that I can show others that don't use a BB the functionality of my app.
It's probably pretty easy to take your Webworks app and alter it for another framework like Adobe AIR or PhoneGap (I haven't tried, but intend to at some point).
From experience, Webworks seems to be easier to develop in terms of UI. But in terms in functionality, there isn't much. I don't know if they've changed this, but before, if there wasn't specific functionality in Webworks, you could create your own by porting the Java code over and creating your own extension.
I would say that using J2ME, would be the better choice if you need more integration with device functionality, rather than UI.
I'm developing an application for Android, and I'm thinking that it's functionality might be useful on other (Java-running) platforms (say a regular desktop app -- although I hope that the other platform(s) involved are immaterial to the question at hand).
It's unlikely that the UI will be in any way portable (there's just too much of a difference between a good touch-capable, 4in screen UI, and a mouse-and-keyboard 19in screen UI), so I'm happy enough reimplementing that separately.
However, the core "business logic" (ugh, horrid word) and model (data storage) classes could, in theory, be reused in managing the core app. I've noticed that there aren't a lot of classes I'm writing that don't end up referencing some Android-specific bits (I've got XML resources files, images, and SQLite databases, as examples). Basically everything I've written so far has at least one Android-related import.
My question is twofold:
What tools are available out there to help me use Android-related classes and features (eg resources, databases) on non-Android platforms; and
What classes, features, etc of the Android platform should I completely avoid using (for the sake of simplicity, let's exclude UI-related items) due to non-portability, and what should I use instead to improve portability.
Answers that consist of "hahahaha, you're doomed" are OK, as long as there's some rationale provided.
(P.S. I'd make this community wiki if that was still available; this seems like a perfect CW question to me -- a list of Android portability tips and tools)
Looks like you have already identified the key point by keeping UI and biz logic / model separate.
Also sqlite itself is used not only in Android. But of course the way you interact with it (e.g. SQLDBOpenHelper) is different again.
So I guess having the biz logic and model as separate as possible is the way to go.
You can then put a wrapper around it (e.g. "Data Access Object " pattern which talks to the specific DB).
Still keep in mind that the users experience is best when you are as specific to a platform as possible on the UI side.
Example: there is an App (Push & Ride) on the Android market, which seems to run in a J2ME emulator. So screen input does not use the normal soft (or hard) keyboard of the device, but a simulated phone keyboard with the "abc" "def" combos on the number keys, which makes data entry a bit strange.
This app is for sure very portable (and its functionality is really great), but it just does not feel right.
When you want to go multi-platform, you may perhaps also look at things like Appcelerator or Adobe AIR
I started off doing something similar - I wanted to write an app for Android, Blackberry and J2ME. Conceptually, you can layer your design such that platform-specific components (UI, network access, data storage) are separated from the core business logic.
In practice, I don't find this satisfactory. The issues I faced all related to the core version of Java being different in the different platforms (in Blackberry it is based on J2Se 1.4, while Android used Java 6 as base). This led to annoyances like
Not able to reuse code that uses generics
My preferred classes not being available uniformly (for example, forced to use Vector over List)
I have opened discussions regarding this on SO (here and here), but couldn't reach a conclusion.
The logging layer can be made portable by using the Simple Logging Facade for Java(SLF4J) which is available for java/log4j and for android.
Also,you can try this out
http://wp7mapping.interoperabilitybridges.com/Home/Library?source=Android
Contains documentation and tools to map your android app to windows phone
Also read this,even though it contains instructions specific to android - windows phone interop,im sure they apply to other platforms as well
http://windowsphone.interoperabilitybridges.com/media/49652/wp7_guide_for_android_application_developers.pdf
What I do is create a web service outside of the android app which can be used by the android app as well as other systems (websites, windows apps, iphone apps etc).
A simple REST web service which supports JSON is a good example to fetch data and also insert/update data. JSON is particularly suitable because its so lightweight, and doesn't require alot of bandwidth which is great for slow mobile connections.
This way you can store your models/data storage outside of the android app, and it can be used by other apps very easily.
The database layer can be made more portable by using android jdbc or by using a database abstraction layer/object relational mapper/ActiveRecord implementation.
Has anyone tried make android.database(.sqlite) runnable on a non android system?
If you carefully separate business logic from UI and android perks you would be able to reuse it in desktop environment. Android is quite different from it in intialisation and application lifecycle - abstracting creation and setup of BL is also necessary.
Usefull pattern for this purpose would be dependency injection. There are different frameworks around, and some are more suited for android (like roboguice) or desktop (spring or picocontainer or guice).
Android appliactions are very constrained in memory, and this puts limits on what frameworks you can use there. So you may need to abstract data storage as well ( hibernate comes handy on desktop / server side , but too heavy for mobile device)
I'm inclined to suggest trying out the new native extensions for Adobe Air. It allows you to create a device-specific chunk of native code, and connect it to the Air framework, accessing it as you would other objects in Air. (cf. http://www.adobe.com/devnet/air/articles/extending-air.html). This allows you to keep the Android-only code as is, and then replace that code with iOS, Windows DLL, etc. code as needed.
This doesn't solve the problem of translating Java code to other languages/platforms, of course. Still, some of the logic you are doing natively may very well exist already cross-platform in Air. For example, you can access the camera in Air in all supported OSes without writing any device-specific code.
You will probably need to go beyond the current Air classes, so some examples may help:
Android speech-recognition
iOS batttery
Windows and Mac tutorial
NE tutorial
I am currently trying to implement a database compatibility layer for Spring-Boot-JPA/Android-Room:
"compatibility layer" means my Service-layer-code is pure-non-android-code that can be used in android and in spring-boot. The Service-layer-code uses a common java-repository-interface that is either implemented in android-room or in JPA.
Currently i am stuck here:
Howto use methods of CrudRepository<T, ID> (or SimpleJpaRepository<T, ID>) in a Spring-Data-Repository-Fragment method?
Is it possible to develop an application easily available on the web that also can be distributed on DVD (installer or started from the dvd)?
For the moment, we use static html (frameset!) pages (generated by xml files), with one difference: pdf's are only on the DVD version, the web version only shows a preview of these files.
Can this be done with JavaFX, OpenLaszlo or are there better options?
(for example: turbogears, and using tg2exe for DVD version)
I think if you design it correctly to begin with, a JavaFX app can be interchanged between web-app and desktop-app relatively easily. However, I've only done this with very simple apps (specifically, Tic-Tac-Toe!), so I'm sure there might exist some caveats that I am unaware of (thus the "design it correctly" catch-all). ;)
Why don't you just provide the PDFs in your current web version, rather than redeveloping everything? I'm not aware of any browsers that don't support in-browser PDF reading anymore.
Yes JavaFX or Flash applications can be used to develop applications that run in different contexts.
However, it's not clear from your question why these would be preferable over your current solution.
If the information your sharing is primarily text and you're using DVD because your audience is primarily located in area with bad Internet connectivity, then you're current approach probably makes more sense. JavaFX or Flash might be more fun to write for developers but maybe doesn't serve your audience.
I would suggest that if you are shipping DVD and are looking for ways to make the DVD more useful than as a PDF delivery system would be to add video to the DVDs. And then maybe it would make more sense to use JavaFX or Flash to drive the UI.
Yes, it is possible. If you use JavaFX you will be allowed use multiple deployments. For example, NetBeans 6.7.1 with JavaFX creates several possible deployments from one project. Then you can publish this application on web, DVD, etc. You will need to slightly customize standalone deployment for DVD to be able e.g. start it as autorun if necessary. JavaFX is good choice.
This seems like a job for flex, however I know better little about it to give a better answer.