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
Recently I came across Cross Platforms for mobile app development, to name few:
RhoMobile,
Appcelerator,
WidgetPad,
PhoneGap,
MoSync and many more....
I am confused whether it's really worthwhile to devote time to learn these. There are countless advantages one can think of developing app which can run on all major platforms but what if our app requires extensive usage of API's of that particular OS. On top of that, Android, iOS release new versions of OS, say, almost every year and hence to cope up with that the cross platform environment have to be updated and thus an updated API to develop!!
Consider a case, we are using Facebook API in our app. Now if we use a cross platform mobile development environment then wouldn't it be like we are using one api to access our main platform i.e. Android or iOS and then sub-level api to use Facebook? If we carry on these sub-level usage then isn't this technically getting hardware resource hungry and time consuming. Also that, the flexibility of using third party API's might also reduce.
I am also excited about cross platform development but just wandering whether is it right time to invest time as these cross platforms too are on their initial development BETA phase.
To answer the 'headline' of your question, "Cross Platform Mobile Development worthwile or not?", it depends on the complexity of your application, but in general terms I think the answer is 'YES'. If you have need to create the same application for Android, iPhone, Windows Phone 7 and BlackBerry this will require creating the same application four times over! Also, the languages and APIs for each are very different, it is unlikely that you will find a developer that can program for all four.
Regarding the frameworks you listed, there is already a pretty good overview of the differences between three of them here:
Comparison between Corona, Phonegap, Titanium
You are right, most are in Beta, or some early form. Personally, I would recommend learning HTML5 / JavaScript / CSS, typically these are the languages that are being used to deliver cross-platform mobile applications. If you have a good understanding of the underlying technologies, you can transfer your skills from one cross-platform mobile development framework to another.
More recently I've created an open source project http://propertycross.com that helps select a cross-platform mobile framework by showing the same application implemented with Sencha, Titanium, Xamarin and more ...
It totally depends on your application requirements. Please note that these cross platform mobile app development frameworks does not support all phone features. They mainly supports features like - GPS, Camera, Contacts, Storage, Accelerometer, Compass, SMS, Email etc.
They does not support complex features like NFC, SIM Card Info, hardware access etc.
Out of all the mentioned tools, I will recommend PhoneGap tool.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 8 years ago.
Improve this question
I have so far been a partly QA Automation/partly Web developer person, mostly been working on QTP / VBScript for Automation.
Soon I will be moving on to a new project as Automation Architect.
While I have the overall approach and idea for Automation Framework, that I want to develop, ready in my mind, I need some help on deciding the Automation tool. I would love to use QTP as I would be able to use the full library for low level functions as is from my current project.
However one thing where I feel restrained with QTP is ‘cross browser’ support, I feel only IE can be targeted best with QTP, Firefox/Chrome support is still bit limited. Also, QTP doesn’t allow to test on multiple browser windows at a time. (I maybe wrong here, the latest QTP version maybe supporting this, and if so, I will appreciate if you can share your experience) Our target apps would mostly be Web Application and target Web platforms would be IE/Chrome/Firefox/Safari/Opera.
So I am also thinking to give Selenium or Sahi a try.
Being a Web developer, I can say I am good at JavaScript, so adapting to Selenium should not be a big shift for me.
However before I go ahead with getting my hands dirty with Selenium, I want to hear the thoughts from the expert community here.
What do you feel, how good has been yours ‘cross browser’ automation experience with Selenium /Sahi, or your grievances w.r.to Selenium. Also how much Selenium would be helpful to when it comes to something like the flexibility we get from QTP in terms of opening the door for Automation Developers to VBscripting world – we can extend the scripts using lot of supporting VBScripts , system level scripting, or networking related scripting or IE settings programming , runtime DLL registrations or other batch files, database linking (ADODB), using 3rd party APIs / Web APIs etc, XML programming, using .net libraries etc.
thanks in advance, much appreciate sharing your valuable experience.
This is an ongoing debate. However, I, from my experience, would say SELENIUM. There are of course some advantages of using QTP. However, with the ongoing technology in development world selenium is much better tool. Having the capability of implementing the OOP and taking it's advantage is a big factor here where qtp easily fails. Thinking abount angulars, other ajax technology where selenium is improving day by day and qtp is not. And, think about working in agile team side by side with developers who are building your app with java/c#. You can pretty much share there knowledge and techniques to equally support your project where using qtp your project set up will be whole lot different. And, at any case if you need help from google selenium wins without any doubt.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 11 years ago.
I'm struggling trying to figure out if I should go native or if I should go with the web app approach for a particular project. I understand the benefits and the differences in approaches. The biggest question in my mind is what do I lose access to by going with a web app versus going with a native app?
I know there are certain things WebKit can handle that used to be the domain of native apps only (i.e. access to geolocation information). I also know about different frameworks for adding this functionality, like PhoneGap. I'm not looking for any hybrid applications. I'm talking about differences between an app that runs inside Safari and one that is native Obj-C.
Preferably, this will be iOS information and not Android information, but either would be interesting.
Core Data (data storage on the device)
Camera (except with custom tweaking)
Accelerometer
Ability to run and at least provide some UI when no internet
connection is available
The iOS App Store distribution method
Web Apps have to go to the server for everything (UI, data, etc).
Native apps only need to go for fresh data and authentication. This
usually results in a slower and more clumsy user experience.
TableViews and ViewControllers (the MVC model)
I am sure there are more. I was in the same dilemma as you about a year ago. I decided to take the plunge and learn objective-c so I could do it natively. I found that the extra time taken to do that was made up for by the ease at which the UI can be generated natively. The positioning and rendering is so precise and cuts down on the trial and error methods that are usually used when laying out HTML and CSS.
I am glad I did that, I can now crank out a fully functional, complex web-service fed app in a weekend and I need minimal help from my graphics artist to do it.
HTML5 is pretty powerful for webapps, but there are still some APIs missing in the browsers - such as getting access to camera and microphone (the Device/getUserMedia API is still in draft). You can play audio stuff, use accelerometer, gyroscope, geolocation and websockets, but all of this is handled via javascript. This is not bad, but it depends on the browser and its features.
In a native app you can use all of those sensors, but you will have to implement these features explicitly for every desired platform (iOS/Android/WinMO).
And you can use graphic languages (OpenGL) in native applications / WebGL isn't yet supported on mobile devices (afaik). Native apps can use the full potential of the hardware, webapps are limited to their browser's javascript performance.
Web apps (or apps that run on the browser (webKit Engine)) are limited access to the underlying device functionality due to security concerns..
So they cannot access many of of the underlying device functionalities like -
- accessing device contact list and other sensitive information stored in the device
- access to device hardware - like sensors / bluetooth / wifi etc
- make use of underlying OS API calls.
So depending on your application features you will have to device the best for your app.
Native apps can use pre-compiled pre-optimized native ARM code, and the benefits that developer driven compilation provides. Apps that require significant computation (game physics, audio DSP, etc.) will have better performance, either due to lack of interpreter overhead, more compiler optimization, or not requiring communication overhead and latency of offloading the task to a remote server. Native code virtual reality creation and similar types of real-time feedback may also have less lag. The lesser processor cycles or communication needs arising from a natuve code solution might also consume significantly less of the user's limited battery life.
Certain iOS subview animations are only possible or run more smoothly from the native code API than from JavaScript.
User privacy and security concerns may also limit or completely restrict access to certain user data and sensors (photo album, mic, front camera) from Safari web apps, to which native apps currently have some access.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
Is there is any Scripting languages is used for mobile application development?
For example java script,vb script is used for web development.Like any scripting language is used for mobile application development along with J2me.
Thanks & Regards,
Sivakumar.J
I have been successfully using Lua language for MIDP and Blackberry platforms for quite some time. My experience is quite positve and I strongly recommend it.
You could use a CLDC 1.1 port of Lua Kahlua2
Do let me know if you have any queries using it.
Edit: I stumbled upon this link HECL, which also looks okay. But the language seems unpolished for my tastes.
For Android, sl4a is good choice with a rich API's included & support for many scripting languages ex: Python, Perl, lua etc.
I'm not sure if this is what you mean, but Android has SL4A (Scripting Layer for Android) which supports lots of scripting languages, among them Python, Perl, JRuby, Lua, BeanShell, JavaScript, Tcl.
Symbian supports Python (with Qt bindings from Nokia) and Ruby.
When using standard web technologies to develop web applications, a big constraint is the context in which the application should run. In particular the mobile context is very different from the desktop one even in the design of web applications. Many aspects should be taken into consideration related to hardware and software constraints to which every mobile device is subjected.
It depends onrequirements for your application. For example:
If as better as possible performance is needed,than a low level language like,Assembler, C or C++, has to be used
If as better as possible UI is needed,than a high level language, like Java, C# orVisual Basic, has to be used
It is recommended thata prototype of the application and its UIis designed with a high level language.
Also, it is not just a question of some programming language. It is a combination of many-many factors and
one of them is a right set of helperlibraries. An UI library, like QT, could significantly speed up the
development process.
In overall, your application could use any set of different languages and helper libraries.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
At work I use mostly the .NET Compact Framework 3.5 for developing applications that run on smart devices. Our devices are not phones or handhelds - they are measurement instruments which you get with a whole punch of features. Our application is pretty advanced - we are even using a N-Layer architecture, a self-made GUI framework and even dependency injection (we built our own as the ones other there are not lightweight enough).
So what's the most advanced things you did with the compact framework?
What's currently missing (for example a mocking framework, as there is no Reflection.Emit on compact framework)?
How are you developing your applications? Are you deploying your application every time to the device. In our case this is very slow, as the solution consists of 30 projects so we have a Win32 Version which runs on the PC.
We've done a plant-floor monitoring system that acts as a data server and a web server collecting data from PLCs and creating dynamic web-based reports all in the CF. We've created a peer-to-peer notification and file sharing system. We've done vehicle tracking and dispatching systems. We've done smart-farming applications that monitor loads of data from a tractor and couple that with location and previous year data, plus quite a few others. So I guess you could say de've written several highly-complex things using the CF.
There are lots of "missing" pieces, but most can be worked around. The most obvious missing piece that can't be worked around is the lack of EE Hosting. Reflection pieces for mocking would be nice, but we can live without - it just makes test more of a bear. The lack of Hosting makes several things simply impossible.
As for deployment, it's all about configuration. The Smart Device Framework itself, when coupled with all of the unit test stuff, is something like 45 projects. Deploying isn't bad as it only recompiled and deploys changes, and I often adjust the configuration of test applications to not deploy all projects, but only the main one. That should auto-deploy all references (eliminating the double-deploys you're probably getting). Also having all projects output to one common directory and setting "Copy Local" to false improves things quite a bit too.
One of the most useful things we do with our .net cf application is work hard to make sure that they can be re-targeted to the full framework. This means you have a second desktop project or a unit test that actually runs your entire application on the desktop. There is a bit of work to do if you are using device specific functionality via pinvokes or device only APIs, but the effort usually pays off because:
You can quickly run/debug your application without having to wait for an emulator or device to spin up
You are forced to architect your code in a way that device specific functionality can be mocked and tested
In many cases you are part way to having a desktop version of your application as well as the device version
It probably goes without saying that in the end, testing will need to be done specifically on the device, but during development and the quick code/debug cycles it is really nice to not wait on the emulator. I remember Daniel Moth posting something about how to actually create a device deployment target that is your desktop computer to achieve this same effect. Maybe someone else can find a link?
I have done Win CE app for industrial PDAs for route sales from pre-loaded inventory and clients list. It gets GPS coordinates, uses scanner to collect data, transmits data over GPRS/EDGE of sales made in the device. The app also prints a receipt (linked to protable printer ober BT).
I wrote an app that monitors the statistics on my self-made blog by interfacing with a WebService.
I have developed a multi-language dictionary. Using one code base on Windows, PDA and via MONO on unix and MAC.
Basically the application is complicated because we use multiple databases that are large. We were able to tweak the data access performance and lookups on large tables are almost instantaenous.
Small devices are not very powerful, but if you design for the way they work you can get good performance out of them.
I made an app to collect measures of any magnitude (for weather), using an n tier app, with MVC and using db4o as a database... Pretty impresive
We're about to build a Blackberry application but would love some input on whether to implement using J2ME (MIDlet based) or Blackberry native (UIApplication).
I understand some of the tradeoffs. J2ME will be more flexible if we want to port the app to other devices. RIM has better support for Blackberry native.
The place I'm still lacking information, though, is on the UI side. We want to build an app that has a great user experience, and one that looks like other apps BB users are accustomed to. Can we do this if we go the J2ME route?
Apologies for the somewhat subjective and less technical nature of the question.
I've tried it both ways - building a pure MIDP app to run on BlackBerry and non-BLackBerry platforms and building a separate BlackBerry app (often using much of the same business-logic and networking code as the MIDP app). Definitely go the BlackBerry native route.
It's all about the BB UI classes. They'll give you the ability to (among other things) respond to the different type of menu events (trackball and menu key), respond to BB specific key codes, if you're interested in the Storm take advantage of the orientation sensor and touch support. Plus they're a much richer set of UI elements to work with. You can build up a lot (but not all) of what they do in pure MIDP, but end up customizing so much of it for each platform that you won't save anything in the end. Starting with the BB UI and customizing saves a lot of time and effort.
Even in gaming applications, or for applications where you're custom drawing all your components, you have better access to the BlackBerry graphics APIs and get better performance going the BlackBerry native app route. And you still have better detail about input events.
Finally there are some nice lifecycle things you can do with BlackBerry native apps, like pushing to the background, or auto-running on system startup that you can't do with MIDlets, which may be of interest depending on your application.
Also think about market - if you're planning on supporting BlackBerry right away, and then maybe other MIDP platforms down the road, it's usually a better plan to execute the best you can on your initial platform. There probably won't be much of a reason to port to MIDP later if you don't succeed on BlackBerry first.
BlackBerry is a very difficult platform to program for. I went the native route and found it to be very poorly documented and overall just a miserable design to work with. I did feel it to be necessary because you will lose the ability for certain features (scroll wheel?) if you go the J2ME route. It's a tradeoff and you'll have to choose the one that fits better for your specific need.
I have been working with J2ME since 2002 when the Nextel/Motorola phones were in the forefront of J2ME functionality. I deal primarily with non-gaming applications. Today with J2ME evolving and more phones conforming to the JSRs my application continues to port smoothly. This year I finally got around to moving it to a Blackberry device. Two days later my application is fully functional on a Blackberry. The application is purely generic J2ME and uses many of the JSRs (location, bluetooth, xml, etc ). A strong UI design helps. I extended some of my UI classes to support the QWERTY/SureType keypads. I have used a variety of native applications found on Blackberry devices (not games) and I have yet to justify any reason to venture off to the RIM API to see what I would benefit. The arguments expressed above by other fellow programmers further prove that there is very little to gain unless you are purely devoted to a Blackberry device platform.
Without knowing the scope of your application, meaning which devices you will target, another thing that you will need to take into consideration is the ever expanding differences in input for each BlackBerry model. Some devices, like the Curve and the Bold, are standard QWERTY pads where other devices, like the PEARL, have SureType pads. And then there's the Storm which supports both depending on the orientation of the screen. Also, the SureType pad needs to be used as a standard number pad if the user has it set that way. The native APIs have support for all of this where you won't have that luxury with standard MIDP.
Another tip when designing your user experience, I would get my hands on a few different BlackBerry models and try out some of the apps that come standard as there are a lot of shortcuts that users become accustomed to using that you might not even realize exist. For instance, the SPACE bar pages down. This is huge for reading docs, however I have a third party RSS feed reader that does not have this functionality and I always attempt to use it first before remembering that it doesn't exist in this app. That kind of small detail can make a huge difference to BlackBerry users.
There is a way in between: You could use J2ME-Polish and code natively in J2ME. Polish will add the look and feel of a native BlackBerry app to some extent. That has the advantage of porting your app to other J2ME phones and not be limited to BlackBerry.
I agree with Anthony, I'd go with the BlackBerry specific APIs for BlackBerry apps. J2ME is just not portable, and BlackBerry has a lot better support for their proprietary APIs.
From my experience: stick with the native BlackBerry UiApplication. It is the best for BlackBerry and provides the best user experience for BlackBerry users. You can't copy that with J2ME easily.
J2ME is simple to develop. And, BlackBerry API has many feature also you can use restricted class with simple signing. BlackBerry sells their sign certificate and it is cheap. 20$. You can use this certificate to sign and use all restricted class. In J2ME, sometimes you must use more than one certificate, even you can not use all phone capabilities. So, my suggestion is, use BlackBerry native API and some J2ME Wrapper Codes. So that, you can code easly as J2ME and can use all capabilities of BlackBerry native API.