Skip to content

Developer resources, we’d like your input

June 30, 2010

We’re busy building out our plans for the technical content & tools we will have on, and we’d like your input so we can deliver, to you, the best resources for your widget and native app development. Below is an example of the types of resources we are looking to cover,

  • Getting started (including – API’s / reference, Tutorials, Code snippets, Best practice, Localisation info for markets)
  • Tools & Resources (including – SDK / Packager / Emulator, Signing, Testing, QA)
  • User Experience Design (including – Guidelines, Patterns, Showcase apps)
  • Publishing (including – How to guides, Vodafone 360 Shop guidelines)

To enable us to capture your ideas and thoughts please leave a comment to this post with your feedback, covering the specific content, topic areas, themes (such as Augmented Reality, navigation) or particular API’s that you’d like to see us include. Please provide your comments by 23rd July.

As an incentive for your input we’ll do a random draw on 26th July from everyone who has left usable feedback before 23rd July, and the winner will receive a 360 Samsung H1 device.

Thanks in advance. We want to ensure we deliver the best developer experience for you!

12 Comments leave one →
  1. June 30, 2010 3:14 pm

    Good morning,

    According to publishing through JIl.ORG, during the publishing step number 2, the selection of device classes selection is too generic, and the combinations can cause misunderstandings from the QA, causing rejection.

    I report my experience.

    I developed a widget for Vodafone Symbian Runtime , and only for low resolution Nokia classes (N95, E65 and so on).
    In the publishing page, i checked the options:
    -Resolution: Low (240×240, 240×400, or 320×480 resolution; e.g. Nokia N95 or Vodafone 360 M1).

    – Run-time version: Vodafone Apps Manager (Symbian)


    I wanna remind that we don’t have the possibility to change the string in brackets, and

    as you can notice, selecting Low resolution, the description includes also the string “Vodafone 360 M1”, that it written as example, but this cause many problems with QA.

    More than one time my widget was rejected cos QA tried to test my widget also in LiMO Platform, even if the only run-time specified was Symbian.

    Other times, rejected cos in the description string appeared also “Vodafone 360 M1” or a wrong resolution for Nokia devices.

    In the end after i signaled the problem, everything was clarified, and since a bit of time QA ignores that wrong description, and test only for the Run time specified.

    Anyway, the problem is half solved , cos a widget made only for symbian appears in also compatible with “Vodafone 360 Samsung M1”.

  2. July 1, 2010 3:11 pm

    Take a look at Wish – List topic of JIL forum:

    Until know this is wish list:

    Include a function which keeps alive screen light, like the getAttention method in opera widget object.

    During the publishing step, the device classes division is too generic, and this can cause rejection from QA very often

    When you make some changment to the System, it will be very useful to find some warning message advising about modifications avoiding to us the publishing process, this would allow not to have then zombie widget due to a temporary malfunctioning of the system

    Make API working in all devices equally, inform in API which Vodafone manager & device supports which function.

    FullScren Mode.

    Block in Portrait/Landscape mode.

    Create free access Bug Reporting website (Bugzilla), so developers could easily inform you about issues and learn themselves about traps awaiting and ways around.

    Full SVG support in all devices.

    Full Screen mode suggestion –> (ex. on Android provide way to hide/show bottom keys (Stop and Minimize))

    (Community website) Make landing page intro paragraph text not an image.

    [UPLOADING WIDGETS] Also able to target single devices instead of just device groups

    Accelerometer API: Would be nice to have an onShake callback, so that each device can call it when a shake is detected. This will help, in case not all accelerometers on all devices behave the same.

    Even perhaps a restful, static application (like a Sinatra app) based on the API urls in the documentation themselves (i.e. that link to API specific content, available everywhere. This would also help deliver platform content much more easier as well as allow developers to track changes in those.

    [JIL DEVELOPER WEBSITE] Be able to see the download statistics of all widgets for all markets in one convenient page.

    [JIL API] Be able to set the volume of audio/video playback with a method like Widget.Multimedia.setVolume(8)

    – When a bug is reported or an item is suggested, it would be nice to have a rep from JIL actually respond. Either with a “we know, we’ll fix it” or “nope, not fixing that” but something, anything! A great example of this can be found here: Opera Form response Notice that the person responding from Opera had the log on their profile and we can tell it’s an official response.

    Explain better how it works a widget version update. In my personal experience, having a widget version 1.0 , no update to 2.0 worked. If in the newer version i leave the same ID and i change only the version number , Jil system return an error advising that ID is already in use.

    GPS in Androids should throw error when disabled in OS settings. (as it happens with sound playing)

  3. July 2, 2010 3:03 pm

    Let me start by saying that this is a great initiative and asking the community is a great way to solicit feedback. Here are my suggestions and wishes.

    Discoverability: Right now, finding information about the specs, what phones support what version and what sup-section of the JIL API is a very hard thing to do. All of the documents are in PDF format and the sites that contain them actually have documents on them that are now considered old and are no longer relevant. It would be great to see all documentation provided as web content (i.e. not PDF) with RSS feeds so we can easily see when things change.

    A chart that is up to date, that includes every device that Vodafone offers and specifies:

    which version of the JIL spec it supports
    what subset of the JIL API it supports
    any known bugs in that devices runtime implementation (the developers on JIL are pretty vocal about those 🙂 )

    Feedback: It would be great if there was one or more Vodafone/JIL champions on the forums. Helping the community out and answering as many questions as possible, instead of letting the developers guess. This person(s) should be clearly identified as belonging to JIL or Vodafone, which will lend them and their answers instant credibility. The more active and accurate feedback that Vodafone can provide to it’s developers, the more of a community you’ll be able to build.

    Open Source Samples: Let’s help the new comers and the veterans out by providing free (MIT licensed?) sample code. We’ve already started doing that, let’s even work together, after all… that’s what open source is all about 🙂

    I look forward to seeing what Vodafone makes of these comments. This is a great first step and please remember that the community is here to help if needed 🙂

    Best regards,

    Dan Silivestru

  4. Brent Lintner permalink
    July 5, 2010 6:03 pm

    Great idea! Here are a couple of things I wanted to bring attention to and/or elaborate on (though others have mentioned them already).

    1. (cant take credit for this, via the JIL wish list). A bug tracker would streamline bug tracking immensely. There are lots of trackers out there already as well. This may be more of a JIL specific thing but still would be great!

    2. Web based API docs. PDF’s are not ideal. For example, use a Sinatra application (on Heroku for super fast deployment) to provide a RESTful based, easy to access documentation. You could even base the routes (urls) off of the object semantics (and maybe even their hierarchical forms).

    i.e “”

    This could apply to any other documentation as well.

    The vf developer site is great so can’t really suggest much there :-). Would be nice if took from you guys in a slick design and good front end presentation. Kudos.

  5. July 6, 2010 9:09 am

    It’s cool to see that Vodafone is developing a series of Standard UI Objects (sliders, Carousels, and so on), but at the moment in your website, it is available very few examples, and very few documentations about Vodafone Design Patterns.
    It would be nice to create a dedicated web page about the progress of your UI standardization, fully documented , and with simple examples,this would allow us, to experiment much more about a standard widget Look & Feel, and start more easily to build Cross-Platform apps.

    With your incredible work you are doing expanding day after day set of devices which support your platform, having a solid Vodafone base UI library from where to start, it would be really appreciated from all the developers, cause at the moment, resources like UI Jquery , DoJo and other, makes a cross-platform experience a bit messy :))

    Best Regards
    Carmelo Maiolino

  6. Frustrated permalink
    July 6, 2010 11:56 am

    My #1 item: a list of business contacts in Vodafone companies that are open and willing to listen to developers?

  7. July 8, 2010 3:35 pm

    Thanks for all the great feedback so far, please keep it coming…Remember we’ll be doing a draw from everyone who submitted feedback for a 360 Samsung H1 device on the 26th July.

  8. MeriWeb permalink
    July 9, 2010 9:52 pm

    Grab the newbies with basic material
    I don’t want to come across as a grasping newbie, but I really think some much more basic introduction info should be available. I’ve had to spend a fair bit of time just getting my head round what a ‘widget’ is and how it differs from a mobile app.

    As a bit of background, I’m fairly proficient in writing HTML and using CSS to style it, etc. I’m used to inserting JavaScript into my pages (mainly stuff that someone else has written) and I’ve got experience of “Writing” XML in Eclipse. I have some very basic JS and VBA coding ability. I’m keen to get into writing mobile apps, but I have a real aversion to doing so for the iPhone!

    Even so, I found the “Getting Started” stuff assumed just a bit too much knowledge of JavaScript, etc, and I think having to dive straight into Eclipse would put off a majority of people.

    So, my suggestion would be i) very basic intro / background to widgets (more about “examples” and “benefits”, and less about “market penetration” and “user demographics”), and ii) material (or links to good quality material) which builds up from next-to-no-knowledge to I-can-write-the-Hello-World-app-and-know-what-every-bit-of-it-is-doing.

    Again, although I’m a self-confessed newbie, I’m not asking for everything handed to me on a plate; I’m already at the stage of loading my (pretty useless) widgets onto an HTC Tattoo, so this isn’t about me. I can see the benefit of having an app-writing process that builds on existing widespread HTML / CSS knowledge, but my impression is that message isn’t being pushed enough to pull in the people who don’t know that they, almost by default, have the skills to start writing mobile apps. A full-on newbie section on the site could capture that audience.

  9. July 12, 2010 2:26 pm

    In my quest to try and create business models around advertisements, I have found no materials and no support from advertising companies on how to integrate advertising solutions in VF360 Widgets. I believe that easing this trouble for developers would create additional revenue streams in your platform.

  10. July 15, 2010 11:57 am

    Currently there are a lot of UI guidelines and API reference documents, but there’s a lack of any good sample code.

    So, contrary to what MeriWeb said in a previous comment, there’s not enough (I couldn’t find any) code examples of best practices implementations like detecting network status, error handling, etc.

    Also, I personally don’t like having the browse the PDF documentation (most of the documentation is provided in PDF format), searchable and bookmarkable html version of the documents would improve the all development experiment.

    Finally, it would be extremely useful to both beginners and seasoned developers to have a video tutorial of the all process:

    1 – Setup dev environment
    2- Design and development of a very simple app with
    3- Troubleshooting, emulator and device testing
    4- Signing and publishing

  11. July 21, 2010 10:56 am

    In Vodafone markets , make an area dedicated to Widgets Apps, at the moment , it’s a bit difficult for user to browse widgets cos whatever categories is clicked (Most downloaded, Best Rated, Suggested) of course are showed the very famous and well known apps and games developed in Java, but this penalizes a bit widgets developers for lack of visibility in your stores. Make a distinction between Java native apps and Widgets can adjust equally visibility.

  12. July 26, 2010 3:54 pm

    Congrats to Andre Goncalves, you’ve been selected at random to win the 360 Samsung H1 device. We’ll contact you separately to arrange delivery.

    Thanks again to everyone for the extremely value feedback. And please feel free to leave further feedback if you have any.

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: