dotMobimobiThinkingmobiForgemobiReadyDeviceAtlasgoMobi

Posted by teknokrat 3 years 51 weeks ago

pic
 teknokrat
mobiForge Newbie
Posts: 3
Joined: 4 years ago
[offline]

The device capabilities are nice but hardly complete. Will j2me capabilities be included?

Posted by atrasatti 3 years ago

pic
 atrasatti
dotMobi logo
Mobile Genius
Posts: 325
Joined: 5 years ago
[offline]

We could have started with a very large list of properties importing from WURFL, from UAProf and other sources, but we know that all these databases are already overloaded with many properties that are hardly used today.

We decided to start from a white page and create something new.

This forum is where we want to discuss with our developers what is most important to them and how we can add new properties that will be useful today and tomorrow.

We are going to publish a little roadmap shortly on the site of DeviceAtlas that will describe where we want to focus for the next addition of properties, but we are very open to suggestions for the next releases. If you have a list of properties that you need for J2ME development, this is the place to discuss.

Andrea Trasatti
Director of Device Initiatives, mTLD

Posted by teknokrat 3 years ago

pic
 teknokrat
mobiForge Newbie
Posts: 3
Joined: 4 years ago
[offline]

I think anyone doing any kind of j2me programming is going to want to know MIDP/CLDC, JSRs supported, Screen resolutions, Max jar sizes, Heap sizes, key mappings, protocols supported, etc. The problem with trying to support some core set of features that everyone uses is that nearly everyone has a different set that they need and if you are missing even a small number of needed capabilities your database becomes less valuable to those people as they will have to reproduce it internally anyway.

You might consider providing the UAProf URL for each device as well.

Posted by atrasatti 3 years ago

pic
 atrasatti
dotMobi logo
Mobile Genius
Posts: 325
Joined: 5 years ago
[offline]

Providing information such as MIDP and CLDC versions, basic JSR's, etc does not sound like a big problem and the sources we have already provide some of that information.

My understanding, though, is that many developers face problems with the inner workings of the API's, specific behaviours of a specific call, maybe in conjunction with other API's or proprietary API's. This had led me to thinking that knowing the basic information that you can find in a whitepaper of most devices would not be enough.

Would you use this information to develop J2ME applications, or would you use it in a web site to deliver applications that other developer have created?

Posted by teknokrat 3 years ago

pic
 teknokrat
mobiForge Newbie
Posts: 3
Joined: 4 years ago
[offline]

Currently we use this information for both building applications and for determining the best application to provision to a particular device. Knowing key mappings, heap size, max jar size, screen sizes, etc are all critical to our processes. Now, it is true that every device has quirks in its j2me implementation but this is a separate issue. whereas it would be nice to have a bug database where all these quirks would be documented I am not going to hold my breath.

Posted by smiler7455 2 years ago

pic
 smiler7455
mobiForge Newbie
Posts: 3
Joined: 2 years ago
[offline]

This comment has been moved here.

Posted by denari 2 years ago

pic
 denari
mobiForge Newbie
Posts: 1
Joined: 3 years ago
[offline]

I also need the heap size for devices. This will allow me to make a list of devices that my application is likely to work on, before we've finished developing or testing the app.