Update: 3” display with 240 x 320 pixels, not AMOLED screen, 3.2 MP camera. More information:
– New Asha platform and ecosystem to deliver a breakthrough category of affordable smartphone from Nokia [‘Experiencing the Cloud’, May 9, 2013] my composite post of the all relevant launch information
– New Nokia Asha platform for developers [‘Experiencing the Cloud’, May 9, 2013] my composite post of the all relevant development platform information End of update
There was a question why I was so affirmative with the headline of Temporary Nokia setback in India [‘Experiencing the Cloud’, April 28, 2013]. The quite remarkable cross-platform development story for Nokia Asha current and future devices is the major part of my affirmative approach. Take a look and convince yourself as well!
Nokia’s cross-platform strategy is aimed at the following value proposition to developers (see in the “Nokia’s own Asha cross-platform efforts for developers (so far)” section):
Consider Co-Development, instead of classic “porting”
As the Category:Silverlight [Nokia Developer Wiki, April 22, 2013] is stating:
Deprecated Category. Please move any articles across to Category:XAML.
the below rumor about the upcoming on May 9th Asha 501, that its design will be like the Nokia Lumias, would mean that programatically the same XAML interface would be delivered by Nokia for a further enhanced Nokia Asha Touch S40 operating system. It is even more likely as the J2ME platform of the Nokia Asha Touch S40 operating system was a few days ago enhanced by the Lightweight User Interface Toolkit (LWUIT) in Nokia SDK 2.0 for Java™, and this is supported by the full cross-platform Codename One development kit from the same name 3d party company, who is also preparing a XAML based 1.1 version of this toolkit for Windows Phone 8/7 (and presumably for Windows 8 as well), thus allowing the same standard Java programming by providing (see in the “Codename One cross-platform offerings for Java developers” section):
1 Java API which is the same for J2ME, Android, iOS, RIM and Win8.
It could also be quite probable that Nokia’s own Asha cross-platform offerings will extended by C#/XAML oriented cross-platform toolkit[s] on May 9th. Then we will have a complete cross-platform story for Nokia’s non-Windows offerings. We’ll see.
Nokia launching Asha 501 on 9th May? [mobile indian, May 1, 2013]
Nokia has sent out press invites for an event on May 9, which could possibly be about Asha 501 launch, and we have strong reasons to believe so.
Nokia may probably launch new phone(s) in the Asha series lineup on May 9th, on which day Nokia has organized an event and has sent out invites to various media organisations. And while the invitation does not specify the subject of the launch, we are pretty sure about it being an Asha series phone as it has been sent by a team that looks after Asha lineup.
Probably, Nokia would launch the Asha 501 which has been in the news off late.
According to rumors, Nokia Asha 501 is to come with design like the Nokia Lumia phones.
Further the Asha 501 is said to come with a 5 megapixel camera with LED flash, and a slightly larger display than Asha 311 which has a 3 inch touchscreen. Most likely this handset will have at least a 1 GHz processor.
Nokia is reemphasizing on its Asha series of phones to strengthen its market hold. Recently Stephen Elop, Nokia’s chief executive officer, had also emphasized that saying, “We have to make sure the product portfolio is as competitive as possible. We are due for a significant refresh.”
#Breaking “Nokia 501” & “Nokia 210” Passed Testing Process by Directorate Post & Telecommunication Indonesia [nokianesia blog, April 9, 2013]
Today, April 09, 2013 Directorate Post & Telecommunication Indonesia publish 2 New Nokia devices which are already passed the testing process to get certification.
There are Nokia 501 RM-902 that should be (Maybe) The next generation of Nokia Asha and Nokia 210 RM 924 that Should be Nokia Asha 210.
Right know, we still don’t have any information about specification and information. We will post if there are any information about Nokia 501 and Nokia Asha 210.
Compare Nokia Asha 501 vs Micromax A51 Bolt [91mobiles, March 16, 2013]
|Nokia Asha 501
– 3.5”, AMOLED capacitive touchscreen
– 320 x 480 pixels
– 1 GHz Processor
– 512 MB RAM
– 5MP rear camera with LED Flash
– front camera
– video recording
– video playback
– GPRS, EDGE, HSDPA/HSUPA, WiFi 802.11 b/g/n, Bluetooth, USB
– Nokia Asha Touch OS
|Micromax A51 Bolt [$79+]
– 3.5” , TFT LCD capacitive Touchscreen, 262K Colors
– 320 x 480 pixels
– 832 MHz, BCM21552 [ARM11]
– 512 MB ROM, 256 MB RAM
– 2MP rear camera with Flash
– 0.2MP front camera
– video recording: VGA @30fps
– video playback: 720×486
– Android V2.3.7 (Gingerbread)
Sections of this post:
– Codename One cross-platform offerings for Java developers
– Nokia’s own Asha cross-platform efforts for developers (so far)
Codename One cross-platform offerings for Java developers
Developers Guide [Version 1.0.1, Jan 24, 2013]
Codename One is a set of tools for mobile application development that derive a great deal of its architecture from Java. It stands both as the name of the startup that created the set of tools and as a prefix to the distinct tools that make up the Codename One product.
The goal of the Codename One project is to take the complex and fragmented task of mobile device programming and unify it under a single set of tools, APIs and services to create a more manageable approach to mobile application development without sacrificing development power/control.
Codename One was started by Chen Fishbein & Shai Almog who authored the Open Source LWUIT project at Sun Microsystems starting at 2007. The LWUIT project aimed at solving the fragmentation within J2ME/Blackberry devices by targeting a higher standard of user interface than the common baseline at the time. LWUIT received critical acclaim and traction within multiple industries but was limited by the declining feature phone market.
In 2012 the Codename One project has taken many of the basic concepts developed within the LWUIT project and adapted them to the smartphone world which is experiencing similar issues to the device fragmentation of the old J2ME phones.
How Does It Work
Codename One has 4 major parts: API, Designer, Simulator, Build/Cloud server.
API – abstracts platform specific functionality
Designer – allows developers/designers to design the GUI/theme and package various resources required by the application
Simulator – allows previewing and debugging applications within the IDE
Build/Cloud server – the server performs the build of the native application, removing the need to install additional software stacks.
Limitations & Capabilities
J2ME & RIM are very limited platforms to achieve partial Java 5 compatibility Codename One automatically strips the Java 5 language requirements from bytecode and injects its own implementation of Java 5 classes. Not everything is supported so consult the Codename One JavaDoc when you get a compiler error to see what is available.
Due to the implementation of the NetBeans IDE it is very difficult to properly replace and annotate the supported Java API’s so the completion and error marking might not represent correctly what is actually working and implemented on the devices. However, the compilation phase will not succeed if you used classes that are unsupported.
The biggest differentiation for Codename One is the lightweight architecture which allows for a great deal of the capabilities within Codename One. A Lightweight component is a component which is written entirely in Java, it draws its own interface and handles its own events/states.
This has huge portability advantages since the same code executes on all platforms, but it carries many additional advantages.
The components are infinitely customizable just by using standard inheritance and overriding paint/event handling. Theming and the GUI builder allow for live preview and accurate reproduction across platforms since the same code executes everywhere.
Codename One Benchmarked With Amazing Results [Codename One – Reinventing the Mobile Development blog, Dec 7, 2012]
Steve Hannah who ported Codename One to Avian has just completed a set of benchmarks on Codename One’s iOS performance putting Codename One’s at 33% slower performance than native C and faster performance than Objective-C!
I won’t spoil his research results so please read his full post here.
A small disclaimer is that the Objective-C benchmark is a bit heavy on the method/message calls which biases the benchmark in our favor. Method invocations in Codename One are naturally much faster than the equivalent Objective-C code due to the semantics of that language.
With 100,000 SDK Downloads, Mobile Development Platform Codename One Comes Out of Beta With 1.0 Launch [Codename One – Reinventing the Mobile Development blog, Jan 29, 2013]
Tel Aviv, Israel – Mobile development platform Codename One is announcing the launch of its 1.0 version on Tuesday, January 29. After releasing in beta last June, Codename One – the first software development kit that allows Java developers to create true high performance native mobile applications across multiple mobile operating systems using a single code base – has garnered over 100,000 downloads and emerged as one of the fastest toolkits of its kind, on par with native OS toolkits.
The platform to date has been used to build over 1,000 native mobile applications and has been touted by mobile developers and enthusiasts as the best write-once-run-everywhere solution for building native mobile apps.
“I have been developing with Codename One for a couple of months now. When you line up all of the other options for development, whether native SDKs, Appcelerator, ADF or others, Codename One wins on almost every front,” said software developer Steve Hannah.
Codename One has received widespread, viral acclaim in technology and business media including InfoWorld, Slashdot, Hacker News, VentureBeat, Business Insider, The Next Web, Dr. Dobbs and Forbes, which named the company one of the 10 greatest industry disrupting startups of 2012.
“We have been thrilled with the success of our beta launch and are very excited to release the much-awaited 1.0 version,” said co-founder and CEO Shai Almog.
Almog, along with co-founder Chen Fishbein, decided to launch the venture after noticing a growing inefficiency within mobile application development. By enabling developers to significantly cut time and costs in developing native applications for iOS, Android, Blackberry, Windows 7 Phone and other devices, Almog and Fishbein hope to make mobile application development increasingly feasible.
The Java-based platform is open-source and utilizes lightweight technology, allowing it to produce unique native interfaces highly differentiated from competitive cross-platform mobile development toolkits, which typically use HTML5 or heavyweight technology.
By drawing all components from scratch rather than utilizing native widgets, Codename One enables developers to avoid fragmentation – a major hindrance found in the majority of competitors – and additionally allows accurate desktop simulation of mobile apps.
The startup’s founders are recognized for engineering Sun Microsystems’s famous Lightweight User Interface Toolkit, a mobile platform used by leading mobile carriers and industry leaders to this date.
Codename One is available for download free of charge.
About Codename One
Codename One, named by Forbes as “one of the 10 greatest industry disrupting startups of 2012,” is an Israel-based technology company that has created a powerful cross-platform software development kit for mobile applications. The technology enables developers to create native applications across multiple operating systems using a single code base. Codename One was founded by renowned software engineers Shai Almog and Chen Fishbein in 2012.
Windows Phone 8 And The State Of 7 [Codename One – Reinventing the Mobile Development blog, April 2, 2013]
Codename One’s windows phone port is close to a public release.
A preliminary Windows Phone 8 build has been available on our servers for the past couple of days. We differentiate between a Windows Phone 7 and 8 version by a build argument that indicates the version (win.ver=8) this will be exposed by the GUI in the next update of the plugin. But now I would like to discuss the architecture and logic behind this port which will help you understand how to optimize the port and maybe even help us with the actual port.
The Windows Phone 7 and 8 ports are both based on the XMLVM translation to C# code, we picked this approach because all other automated approaches proved to be duds. iKVM which seems like the most promising option, isn’t supported on mobile so that only left the XMLVM option.
The Windows Phone 7 port was based on XNA (3d C# based API) which has its share of problems but was more appropriate to our needs in Codename One. Unfortunately Microsoft chose to kill off XNA for Windows Phone 8 which put us in a bit of a bind when trying to build the Windows Phone 8 port.
While externally Windows Phone 8 and 7 look very similar, their underlying architecture is completely different and very incompatible. You cannot compile a universal binary that will work on all of Microsoft’s platforms, so just to make order within this mess:
- Windows Phone 7 – based on the old Windows CE kernel. Allows only managed runtimes (e.g. C# not C++), graphics can be done using XAML or XNA (more on that later.
- Windows Phone 8 – based on an ARM port of Windows 8 kernel. Allows unmanaged apps (C# or C++) graphics can be done in XAML or Direct3D when using C++ (but not silverlight).
- Windows RT/Desktop – the full windows 8 kernel either for ARM or for PC. They are partially compatible to one another so I’m putting them together. This is actually pretty similar to the Windows Phone 8 port, but incompatible so a different build is needed and slightly different API usage.
As you understand we can’t use XNA since it isn’t supported by the new platforms, we toyed a bit with the idea of using Direct3D but integrating it with text input, fonts etc. seemed like a nightmare. Furthermore, doing another C++ port would mean a HUGE amount of work!
So Codename One is based on the XAML API. Most people would think of XAML as an XML based API, but you can use it from C# and just ignore most of the XML aspects of it which is what we need since our UI is constructed dynamically. However, this is more complicated than it seems.
To understand the complexity you need to understand the idea of a Scene Graph. If you used Codename One you are using a more immediate mode graphics API, where the paint method is invoked and just paints the component whenever its needed. This is the simplest most portable way of doing graphics and is pretty common, its used natively by Android, OpenGL, Direct3D etc. and is very familiar to developers.
In recent years many Scene Graph API’s sprung up, XAML is one of them and so is JavaFX, Flash, SVG and many others. In a Scene Graph world you construct a graphics hierarchy and then let it be rendered, the whole paint() sequence is hidden from the developer. The best way to explain it is that our components in Codename One are really a scene graph, only at a higher abstraction level. Windows/Flash placed the scene graph on the graphics as well, so to draw a rectangle you would just add it to the tree (and remove it when you no longer need it).
This is actually pretty powerful, you can do animations just by changing component values in trees and performance can be pretty spectacular since the paint loop can be GPU optimized.
However, the reality of this is that most developers find these API’s harder to work with (since they need to keep track of a rather complex unintuitive tree), the API’s aren’t portable at all since the hierarchies are so different. Performance is also very hard to tune since so much is hidden by the underlying hidden paint logic.
For Codename One this is a huge problem, we need our API to act as if its painting in immediate mode while constructing/updating a scene! When we initially built this the performance was indeed as bad as you might imagine. While we are not in the clear yet, the performance is much improved…
How did we solve this?
There are several different issues involved, the first is the number of elements on the screen. We noticed that if we have more than 200 elements on the screen performance quickly degraded. This was a HUGE problem since we have thousands of paint operations happening just in the process of transitioning into a new form. To solve this we associate every graphics component with a component and when the component is repainted we remove all operations related to it, we also try to reuse graphics resources such as images from the previous paint operation.
When painting a component in Codename One we normally traverse up the component tree and paint the first opaque component forward (known as painters algorithm) however, since the scene already has the parent component painting it again would result in many copies of the image being within the scene graph. E.g. I have a background image on a form, when painting a translucent label I have to paint the background image within a clipping region matching the label…. In the Windows Phone port we have a special hook that just disables this functionality, this hook alone pushed us over the top to reasonable graphics performance!
We are working on getting additional performance oriented features into place and fixing some issues related to this approach, its not a simple task since the API wasn’t designed with this in mind but it is doable. We would appreciate you taking the time to review the port
Codename One Executive Overview [Shai Almog YouTube channel, Jan 6, 2013]
Developer Introduction To Codename One [Shai Almog YouTube channel, Jan 6, 2013]
Series 40 Webinar: LWUIT for Nokia Asha app development [nokiadevforum YouTube channel, April 16, 2013]
– Swing into Mobile – Use the Lightweight UI Toolkit on Nokia Series 40 phones [pp. 81–84 of Java Magazine, January/February 2013]
– LWUIT for Series 40 out of beta [Nokia Developer News, Feb 26, 2013]
Great news for those of you wanting to deliver superior UIs in your Series 40 apps— Lightweight UI Toolkit (LWUIT) for Series 40 has graduated from beta to a full initial release.
LWUIT is an open source Java ME toolkit that supports a comprehensive range of visual UI components, and other user interface elements such as theming, transitions, and animation among others. It helps you create applications with appealing UIs that closely follow the native Series 40 UIs. It also helps speed up development by significantly reducing the need to create custom UI components, which might be needed when creating an app’s UI using LCDUI. LWUIT for Series 40 can be used in combination with selected Nokia UI APIs and all the JSR APIs available on the platform.
Since the last LWUIT for Series 40 release made available in the Nokia SDK 2.0 for Java, development of the toolkit has been continuing at a rapid pace. A number of new APIs have been introduced, including PopUpChoiceGroup, ContextMenu, NokiaListCellRenderer, theme selection, and full-screen mode. There have also been significant improvements in performance, particularly in lists, themes loading, and HTMLComponent. Compatibility with the native full-touch UI has been fine-tuned and many bugs fixed, particularly in command handling and text input.
The toolkit also includes all the new examples created since the last release. These include code examples that provide demonstrations of the Category bar, gestures, and lists. There are also new application examples for birthdays, showing use of the calendar component and PIM API; a slide puzzle; tourist attractions, showing the use of HERE maps and in-app purchasing APIs; and a Reddit client showing the use of a custom theme and JSON. In addition, updated version of two of the original LWUIT examples applications, LWUITDemo and LWUITBrowser, are also included.
The final component in the full release of LWUIT for Series 40 is the inclusion of comprehensive documentation in the toolkit. This is based on the LWUIT Developer’s Library, a library consisting of:
Developer’s Guide, which is based on the original LWUIT Developer Guide and provides technical information about using the LWUIT components
LWUIT UX overview, which is a new section providing a guide to designing app UIs with LWUIT for Series 40 components
If you have the Nokia SDK 2.0 for Java installed, you will receive an automatic notification of the availability of LWUIT for Series 40 1.0. You can then simply follow the instructions to install the update. If you are using LWUIT with the Nokia SDK 1.1 for Java, you can download the update from LWUIT for Series 40 project.
J2ME, Feature Phones & Nokia Devices [Codename One – Reinventing the Mobile Development blog, April 24, 2013]
How many times have we heard this for the past 3 years or so? Sadly the answer is: Yes!
Unfortunately there is no active owner for the J2ME standard and thus no new innovation around J2ME for quite some time (MIDP 2.0 came out in 2004, 3.0 never really materialized). Android is/was the biggest innovation since and became the unofficial successor to J2ME.
Well, if J2ME is dead what about Feature Phones? Should we care about them?
The answer is: Yes! very much so!
Features Phones are still selling in millions and still beats Android sales in the developing world. Recently Nokia shipped the Asha series devices which are quite powerful and capable pieces of hardware, they are very impressive. Nokia’s revenue is driven mainly by the Feature Phone market.
There is a real battle in the developing countries between Feature Phones and Android devices, Feature Phones are still cheaper and more efficient where Android has more/better content (apps & games).
How long will it take Android to catch up? we will see…
In the meantime there is money on the table and a real opportunity for developers to make some money (and gain loyal users who will migrate to Android or other platform at some point)
To win over the competition or at least to maintain its dominate player position Nokia must bring new quality content to the devices, it’s not enough to ship cool new feature phones, the new phone needs to connect to facebook, twitter, gmail, whatsapp and have all the new cool games/apps Android has and more.
So how should you write your apps for the cool new Nokia Feature Phone if J2ME is dead? Luckily there is an option Codename One ;-).
In Codename One You have 1 Java API which is the same for J2ME, Android, iOS, RIM and Win8.
Below are some of the J2ME highlights:
Facebook Connect – did you noticed there aren’t many social apps on OVI?
There is a reason Facebook uses oauth2 which is a huge pain without a browser API, this is solved and working in Codename One.
Java 5 features – You can use generics and other Java 5 features in your app and it will work on your J2ME/RIM devices. You don’t have to limit yourself to CLDC.
Rich UI – If you know or knew LWUIT (Swing like API), well Codename One UI is effectively LWUIT 2.0.
Built in Asha skins and themes
The most important thing is the fact that your skills are not wasted on an old/dying J2ME API, by joining our growing community and writing the next amazing app your skills can target the emerging platforms of the present/future.
Nokia’s own Asha cross-platform efforts for developers (so far)
Series 40 Webinar: How to develop cool apps for Nokia Asha smartphones [nokiadevforum YouTube channel, April 5, 2013]
[25:01] Porting Resources at Nokia Developer
– Porting and Guide for Android Developers:
>>> http://www.developer.nokia.com/Develop/Porting/ [27:46]
Related to the porting vis-à-vis Android & cross-platform slides:
[27:46 > 28:50 > 29:40 > 30:20 > 30:50 > 31:15 > 31:40 > 32:25 > 33:20 Demo: Android porting Frozen Bubble: see https://projects.developer.nokia.com/frozenbubble and the video coming below > 34:24]
Tantalum Mobile [January 1, 2013] Summary
Tantalum is mobile Java tools for high performance and development speed on Android and J2ME. The focus is on practical use cases which can be included in a project to solve frequent needs in an elegant manner.
Life is many asynchronous tasks chained together and running concurrently on background threads with UI callbacks. The result may look like black magic or star wars, but as you become one with the source, the patterns emerge as ecstatic moments of clarity.
Tantalum Cross Platform Library
Tantalum 5 is nearing beta release
As the Tantalum team works hard on the new Tantalum 5 release and increasing support to the Android community, you can track that and possibly help at https://github.com/TantalumMobile/ More on that and the great support Nokia is giving to this open source effort as we release- happy changes and momentum.
* NEW 4.0 RELEASE January 1, 2013 *
New release 4.0 including cross-platform Android and J2ME app development support, simple fork-join concurrency, simple 3 layer caching and Android AsyncTask and more is now available!
Quick Start Guide and JAVADOC: Tanalum4_doc.zip
Source code and examples: Tantalum4.zip
Cross platform Series40-Android example using Tantalum4: Picasa_Viewer
JavaOne San Francisco talk and demos of Tantalum4: JavaOne_Extreme_Mobile_Java_Performance.mp4
Tantalum is a light-weight metal used used to keep mobile phone electronics compact and powerful. Tantalum4 is the 4th major release of a very light and elegant back end utility library for mobile java. With mobile applications, less is more.
This is _not_ a framework. It is a clean and light tool set which at 8-40kB it will _not_ bloat your application. Obfuscation of your release build automatically removes those features you do not use. We do just a few things really well:
The exact same JAR library runs on J2ME and Android– save time and money by reusing your code and add a native UI for each platform
Clean, fast utility model threading with Java7 fork-join-cancel and Android Java5 AsyncTask patterns
Unique async task chaining to feed the output of one Task to the input of the next is easier than overriding existing classes
WeakReference heap and persistent flash memory caching to easily make online-offlne apps which start fast and run reliably in real world mobile networks
Async HTTP GET and POST with automatic retry
Simplified async XML parsing directly into model objects
Simplified async JSON parsing directly into model objects
Logging convenience classes including J2ME USB debug and app profile from phone
The above capabilities work cleanly together to simplify your development. There is no UI assumption in Tantalum4– pick what works best for you on each platform. The bundled example applications are an RSS reader for
Nokia Series40 Asha touch devices
Download the sample apps and give a try. We hope you are amazed at the results and speed with which you can achieve them.
Apache 2 license. Please return your fixes and suggestions to the community here.
* NEW 3.0 RELEASE June 18, 2012 *
WHAT IS NEW
Many, many stability improvements, especially to caching and flash memory usage
Shutdown work tasks and low-priority work tasks are now supported
Support for Nokia LWUIT in the example applications
Support for Nokia full touch phones in the example applications.
Speed. Tantalum3 is wired and optimized even more than before to run well also on slower devices.
You can find a series of nice, short training videos covering Tantalum3 athttps://projects.developer.nokia.com/videotraining
CONTENTS OF THE ARCHIVE (Download link on right side of this page)
Pre-built example applications, run to test on various devices. Testing is mostly on Nokia SDK 1.1 and 2.0 with profiling of the S40 example tested in Oracle SDK.
Pre-built libraries you can include in your application if you don’t want to mess with the source code. There are three flavors: debug including unit tests and verbose errors, usb-debug, and release optimized. To use the usb-debug variant, connect your phone by USB and open a terminal emulator such as puttytel to the serial port you find in Window Device Manager. Use max baud rate and hardware flow control RTS/CTS.
Everything you need to build the libraries and examples yourself
Javadoc for Tantalum3 library
Javadoc for the optional JSON suppliment
* NEW 2.2 RELEASE February 7 2012 *
Example updates with minor bug fix, reorganization of the source into 3 projects make release builds easier, added unit tests.
* NEW 2.1 RELEASE January 24 2012 *
– Series 40 Webinar: Porting Android apps to the Series 40 platform [nokiadevforum YouTube channel, Dec 17, 2012]
– Porting Android and Blackberry apps to Series 40 [Nokia Developer News, Nov 30, 2012]
If you’ve got an application for Android or BlackBerry (up to BlackBerry OS 7.1), your existing Java code puts you in a great position to take advantage of the growing demand for apps from Series 40 phone owners.
To help you take advantage of this opportunity, we’ve started to gather a collection of resources to guide you through the porting process in the Porting to Series 40 library section.
If you are starting with an Android app, the wiki provides basic information on the tools and technology needed, platform comparisons, porting considerations, code snippets, and example porting cases along with the all-important guidelines you need for an efficient port.
For your future apps, you can even consider creating a Series 40 and Android version at the same time, our Picasa Viewer example application will show you how.
If a little hands-on guidance could help even more, why not check out the Android porting webinar sessions we have on 4 December at 8 a.m. San Francisco; 10 a.m. Mexico City; 4 p.m. London and 13 December, 8 a.m. London; 1:30 p.m. New Delhi; 4 p.m. Singapore.
Life could be even easier if you have a BlackBerry app. Most generic Java ME MIDlets can be deployed to both BlackBerry and Series 40 with little more than platform-specific repackaging. However, you might want to adapt the user interface and the look & feel of the app to fit to Series 40 screen-size and UI style. Again, the wiki gives you a pointer to the porting article with code samples that will be enhanced for the later updates of the library.
You can also get practical guidance from an expert, check out our BlackBerry porting webinar on 18 December, 8 a.m. London; 1:30 p.m. New Delhi; 4 p.m. Singapore or view a recording of one of the earlier sessions on our webinars page.
Using our latest Nokia SDK 2.0 for Java, and its integrated Nokia IDE for Java ME, combined with the guidance of the updated porting library, we think you’ll find porting your app easier than you ever imagined.
We’re looking forward to welcoming you to the family of developers who have found success on the Series 40 platform.
– Designing & Optimising Graphics for your Series 40 app [nokiadevforum YouTube channel, Nov 8, 2012] https://projects.developer.nokia.com/frozenbubble
– Introduction to the Nokia Premium Developer Program for Asha [nokiadevforum YouTube channel, April 19, 2013]
Asha Premium Developer Program introduced [Nokia Developer News, March 26, 2013]
We’ve been having a lot of fun lately—we launched the Nokia Premium Developer Program for Lumia back in October, and it proved to be our most successful developer program ever. Our rewards program, DVLUP, has also proven extremely popular with developers, and we recently expanded it to include developers in the UK.
So we decided it was time to bring some “Premium goodness” to Asha development. Today we are excited to introduce the Nokia Premium Developer Program for Asha.
The Asha Opportunity
The Asha ecosystem has a growing installed base of superior but affordable smartphones (such as the Nokia Asha 308, 310, and 311), and with these great devices comes an increased demand for apps. The Asha Premium Developer Program is designed to provide you with tools and services to make developing for Asha faster and easier, increase the discoverability of your apps, and bring you closer to the millions of Nokia Asha users around the world.
By providing you with high-value support and tools beyond what’s provided by your standard registration with Nokia Developer, the Asha Premium Developer Program will help you fast-track your success.
The Nokia Premium Developer Program for Asha comprises two levels: enhanced productivity tools and app promotion opportunities. We know that it’s easier not only to be inspired but also to develop and test when you have a great device in hand, so the productivity tools start with a free Nokia Asha 310 smartphone. To help you with testing, we’re also offering expanded Remote Device Access with more Nokia Asha devices available to you. Finally, you’ll get two free tech tickets for Asha development support, a value of $198 (USD).
Program members who submit a new, high quality full touch Asha app to Nokia Store can apply for app promotional opportunities: greater visibility on Nokia Store, or a $500 (USD) credit to run paid ad campaigns on Nokia Ad Exchange.
Best of all membership in the Nokia Premium Developer Program for Asha is free, although you’ll need to meet certain criteria.