I am building an enterprise application using HTML5 for Blackberry OS 6.0. I am planning on using PhoneGap for developing the application. I found out that Blackberry also has something similar called WebWorks.
What are the differences between WebWorks and PhoneGap?
PhoneGap-BlackBerry-Widget uses the BlackBerry Widget SDK to support BlackBerry OS 5.0 & 6.0. WebWorks is basically Widget SDK 2.0 and it is intended to support OS 6.0 specific features.
The advantage of using PhoneGap-BlackBerry-Widget over WebWorks is that you can port your application to other platforms that are supported by PhoneGap.
You can still port an application that was written using WebWorks/Widget SDK, but you will need to switch out the BlackBerry-specific JavaScript bindings for the PhoneGap JavaScript bindings (e.g. invoking Geolocation, contacts, or accelerometer).
Looks like WebWorks is specifically for BlackBerry while PhoneGap is attempting to support multiple mobile platforms.
I haven't looked too deeply into WebWorks, it appears to be more tightly integrated with a specific device, a Blackberry
WebWorks is a specific development tool managed by RIM for BlackBerry, while PhoneGap is in the MEAP (mobile enterprise application platform) space where they represent the next generation of mobile development. You develop your app with PhoneGap and it helps you to deploy across all major platforms such as iPhone, Android, Windows Mobile and BlackBerry. If you're a developer then it opens the doors to more phone models and increased opportunity for app sales.
webwork vs phonegap
both are used for build application .using webwork u get for feature for specially blackberry....using phonegap u can use same code for multipal phone like iphone,android..
but i prefer webwork because phonegap add unwanted code to your applicatio due to application very slow ....phonegap + wework in blackberry 5.0 take too much load...it's min size is around 600 kb......
so for blackberry webwork is better than phonegap
One issue to consider is testing and compiling applications.
When testing on devices and simulators it is possible to compile/sign once and access/edit your JavaScript and HTML5 from a remote location, such as the SD Card or a local server. While PhoneGap and WebWorks are both using JavaScript to access native functions, I have found the 'compile once' method doesn't seem to pick up and utilise PhoneGap - this is also the case with the Ripple emulator. In my experience, using PhoneGap requires multiple, time-consuming compilations and launches when testing an application. If testing on a Blackberry device, you need to factor in the time it takes to have your app signed prior to each test and the time it takes for the device to reboot. I'm talking 2+ mins on a simulator or 4+ mins on a device, per each change to your code.
I'm working with webworks for Blackberry and phonegap for iPhone. Not sure whether the problem is with webworks or underpowered handsets but we've had to spend a lot of time ripping features out of the webworks app to get any kind of robustness or performance when running on the device. Static google maps and thumbnail photos had to go.
All webworks apps on a handset share the same pool of memory, about half of the memory available to the BB browser. Webworks also leaks memory. There's a thread a year old on the webworks forum about the memory leaks and no solution forthcoming from Blackberry, just "workarounds". We had to alter the webworks sdk to make the garbage collection more aggressive to stop the app running out of memory all the time. But if other webworks apps are running on the handset and haven't had this GC tweak you will still get grief with memory.
Don't know if phonegap is any better than this but it'd have to go some to be worse than webworks.
If you want to do a webworks app keep the design simple, package all the graphics and assets in the deliverable (we were trying to get icons from an api but have ended up storing them base64 encoded in localStorage) and get it onto a handset asap so you don't waste time adding features that the handset can't cope with.
To sum up, webworks is pretty poor.
PhoneGap : is an application with a webview control that renders your HTML5 and JS. PhoneGap has diferent versions or say release for different platforms like Android, iOS, BB, WP8 etc.
WebWroks : is conceptually the same thing as PhoneGap just that it is owned and developed by Blackberry (Previously RIM) themselves.
Also one most important thing in the context of the question is that, for Blackberry Phonegap uses WebWorks as its base, that is why while developing PhoneGap Apps for blackberry you need to download WebWorks SDK first, the build process is also the same as WebWorks so the benefit of using Phonegap for balckberry is that the same HTML5 + JS Code that you used for say Android will work on Blackberry as well.
However BB OS 7 and below do not have the best WebView Control, BB 10 and playbook are MUCH MUCH Better.
Related
We are planing to develop new app .It has VoIP feature and app is similar to whatsapp.
Since the app has Voip feature we have to go with WP8 silver light. Winrt for WP is not supporting VOIP api.
Can we guess almost all the WP8 devices are upgraded to WP8.1 ? If there are large user base still remains in WP8 we will develop the app using WP8 api's (Using VS2012). Otherwise we will go with WP8.1 api's (using VS2013).I heard there are few performance improvements and controls are available in WP8.1
Any suggestions on this ?
Thanks in advance
All Lumia phones can be updated to WP8.1 and a huge part of users so did.
Just an article for reference: http://www.engadget.com/2014/04/02/nokia-lumia-windows-phone-8-1-update/
On my apps I use analytics to track users and I hardly see few users stuck with WP8.
Update - market share
http://www.gsmarena.com/adduplex_wp81_market_share_surpasses_wp80-news-10062.php
This article is from last October, WP8.1 has been out for about 5 months and it had already surpassed WP8. I let you think the actual quota...
Should you go with WinRT? It depends on your needs. Of course you should use at least WP8.1 Silveright (not WP8). But if your application does not require specific functions only available in WinRT, you might go with WP8.1 Silverlight, since WinRT has still many little performance issues.
There are a lot of new available APIs and features either for WP 8.1 Silverlight or WinRT. I would definitely target 8.1. Users still using WP 8.0 probably don't care that much about apps anyway.
While looking over the Adobe Flash Player/AIR Roadmap (found here) I saw this:
"Flash Player release and debug players are available and supported for Windows 8 Desktop and Modern UI experiences on both x86/64 and ARM platforms."
Which got me thinking about a potential method that apps for Windows 8 might be able to be released using Flash Player.
Currently, using AIR, you can build apps for Android and iOS, as well as for Windows Desktop. But Windows 8 Modern UI and Windows Phone 8 are both unsupported platforms.
So the idea was this. If IE 10 for Modern UI supports Flash Player, and if HTML5 Modern UI Windows apps use IE under the hood in order to run, then supposedly you could wrap a Flash Player app inside of an HTML5 app, and then, voilà, you'd have a Windows Modern UI app running off of ActionScript. (Though it still wouldn't work for Windows Phone 8.)
Well, I have tested this, and (sadly) it doesn't work. I would almost bet that this isn't because the functionality isn't there, but rather it is because of some switch on the backend that prevents this functionality from being used.
So, finally, here is my question, mainly to sate my curiosity on the subject. Does anyone know whether or not such a backend switch exists, and if so, is there a way to switch it?
I have tried the same thing as you and no, I don't think such a switch exists.
I can only assume Microsoft has purposely blocked off ActiveX controls on purpose, since Silverlight also does not work in HTML5 apps.
It is sort of possible that with Windows 8.1 Update 1, they may change this, but I believe it opens up a lot of problems for them from a security / app store catalogue perspective, so would be unlikely.
I have developed an web app using MVC4- mobile and HTML5. Every things is working fine when we enter URL from any phone. But i am wondering how to convert my web app into hybrid app so that i could upload in istore or GooglePlay.
Please help me with the procedure or steps i need to follow and is there any tool other than phoneGap that i could use.
Thanks in advance.
There are few options but I will mention only two of them.
Most commonly used is a Phonegap/Cordova app wrapper framework (Also my main choice). Cordova is a new name for a Phonegap framework. It will give you an access to common mobile phone functionalities (Android, iPhone, Blackberry and WP7+). It is rather easy to use and there are a lot of vorking tutorials available, you can even find them in youtube.
Here's an phonegap link: http://cordova.apache.org/. There you will find tutorials how to install/configure it on all available platforms. This is a older link: enter link description here, it still has usable informations.
If in doubt always search for phonegap examples instead of cordova. For some reason Phonegap is still a mostly used name.
Here's an Phonegap + jQuery Mobile example: http://therockncoder.blogspot.com/2012/07/jquery-mobile-phonegap-and-camera.html, there you will find a github link for Android and iOS implementation.
Through the PhoneGap javascript APIs, the "web app" has access to the mobile phone functions such as Geolocation, Accelerometer Camera, Contacts, Database, File system, etc. Basically any function that the mobile phone SDK provides can be "bridged" to the javascript world. On the other hand, a normal web app that runs on the mobile web browser does not have access to most of these functions (security being the primary reason). Therefore, a PhoneGap app is more of a mobile app than a web app. You can certainly use PhoneGap to wrap a web app that does not use any PhoneGap APIs at all, but that is not what PhoneGap was created for.
Now some disadvantages. With PhoneGap for each platform you have to maintain a different project. The burden for that increases when there is a need to use multiple PhoneGap plugins because you need to search and update different files on each platform.
Mosync is also an excellent solution. This framework has a few things better handled then Phonegap. Like:
With MoSync you’ll have only one project to maintain for all the platforms. For iOS you will still need to use Xcode because MoSync outputs a project for it but, other than just building it, there is no need to dig deeper in Apple’s IDE.
The entire provided functionality for JavaScript is placed in the same file for all of the operating systems. There are no files for plugins because it has none (at least that I know of), but the same extensibility is achieved in ways described in the next section.
If there is some functionality that MoSync doesn’t provide on the JavaScript side, there are no plugins that you can use, but there is another way. MoSync provides a lot of features from the C++ side and if they aren’t accessible from JavaScript by default they can be easily made available. I’m sure that in the future the MoSync team will add more features to the JavaScript library.
With MoSync you are not restricted to only JavaScript frameworks to replicate native UI, you can truly create native UI elements that are more responsive using only JavaScript.
Rhomobile on the other hand is much less used thus a lot less supported.
I heard few good things about this framework but never had time to learn/use it.
RhoMobile applications are OS-agnostic, able to support enterprise-
and consumer-class operating systems including Windows® Embedded
Handheld, Windows® CE, Windows® Phone 7 Series, Apple® iOS, Android®
and BlackBerry®. You have complete control over how applications
behave on different devices. With RhoMobile Suite, you are finally
free from OS design constraints, able to create business applications
that are every bit as elegant looking and intuitive as their consumer
counterparts (This was copied from their main site).
I was thinking of writing a simple android app that would just contain my notes I've made for my job for my own personal reference. I figuered perhaps some of my co-workers would want to use this app too, but most of them use IPhones. I don't own any Apple products and I know nothing about developing for iOS. After some research I've decided perhaps the best approach is to develope the 'app' as a website instead, to be viewed offline. Does this approach make sense, and could I distribute such a product on an Apple device without any issues?
I'd recommend developing an offline application with PhoneGap. PhoneGap allows you to build your app once with web--standards, wrap it with PhoneGap, and then deploy it to multiple mobile platforms.
This month I started to play with Flash Builder because I don't have a mac to create native iPhone apps.
I have made a Flex Mobile Project and an AS3 Mobile project. Both do mostly exact the same and I see great differences in operation speed (AS3 version is much faster). Also the size of the AS3 version is less than the size of the Flex version when I deploy the project.
But one thing disappoints me, the size of a deployed AS3 app (Android) is still about 8MB. I think that is quite huge for a simple app, or is it normal? I did not test the iOS version because I am not an Apple Developer member (is there a trick to deploy an iOS app with fake certificates)?
Resources I have used in the apps:
Two images approx. 35kb in size
A StageWebView
I want to know:
What is the average size of a simple app when it is a native app (apk file)?
What is the difference between an AS3 app and a Flex app except the libraries that re used?
Is the AS3 app converted to C or another language?
Why is the apk so huge (IMO)?
Is there a trick to deploy an iOS app with fake certificates? (just for testing)
Thanks for the answer(s).
What is the average size of a simple app when it is native app (apk file)?
I have no idea. When you were comparing sizes; did you export a release build or a debug version? The full version of my app; using Captive Runtime is 12MB. That includes all the embedded images. I thought that roughly 8MB is the size of the embedded runtime. Of course, if you don't use Captive Runtime then the app will be smaller; but it will have a depency on the user having the runtime installed.
What is the difference between an AS3 app and a Flex app except the libraries that are used?
For all intents and purposes nothing. The Flex Framework will need to execute code to setup the framework and such. In theory this 'impact' is offset by the value that the framework brings.
- Is the AS3 app converted to C or other language?
Not for Android or Playbook. It relies on the Mobile AIR Runtime--which I assume is written as a native app somehow. For iOS there is a more in depth conversion taking place; but no on knows the exact magic sauce; but it the process is much more intensive than Android or Playbook and people believe that your code and the AIR Runtime is converted to Objective C somehow in a way that is not in violation of the Apple licensing agreement.
Why is the apk so huge (IMO)?
Huge is open to interpretation. Without seeing your full app code; it's tough to judge.
Is there a trick to deploy an iOS app with fake certificates? (just for testing)
I don't think so; although there may be possibilities on unlocked devices.
You would like to use Mobile AS3 Project if you want you apps to be smaller and your GUI mainly contains vector graphics and Mobile Flex Project if you prefer to use standart GUI Controls that comes together with Flex framework but adds overhead in size because of controls that come with it.
As of the other questions:
the size of the apps is different on mobile platforms. Typical iOS app is about 2MB - 20MB. It really depends on resources you store with your app. What might be important to you is not to overcome 20MB if not needed because 20MB+ apps require Wi-Fi connection to be downloaded.
(However you should export release build version only as mentioned by www.Flextras.com)
there is no fundamental difference between AS3 and Flex apps - they both compile to the same instructions that executes on targeted mobile platform.
as far as I know (being iOS developer myself) there is no workaround to deploy an iOS apps. You need to use Mac and become Apple Developer to deploy with valid certificate.
to make your app smaller try to pai special attention to the resources you add to the project. Although I believe the size is so big because of framework itself, you would like to use more vector graphics vs. bitmaps when compiling apps with Flash/Flex.
When you export for Android you have an option of embedding the air framework in the application, that way your users don't have to download air. you can export your application without air embed which will result in a much lighter application, however your users will need to download air runtime. http://cookbooks.adobe.com/post_How_do_I_create_an_AIR_application_for_Android_tha-19299.html