Updates from February, 2010 Toggle Comment Threads | Keyboard Shortcuts

  • pit 12:38 pm on February 5, 2010 Permalink | Reply
    Tags:   

    How to capture photos in a Web Runtime widget using APIBridge 

    One of the best features that APIBridge brings to Web Runtime widgets is, without doubts, the ability to capture photos, videos and audio.

    If you don’t know how to build a widget that includes APIBridge functionalities, you should read this article: Build your first Web Runtime widget with APIBridge.

    Now, let’s start with photos, and create a very basic widget with a button that will be used to take a snapshot.

    This is the HTML code used to create this simple widget:

    <body onload="init();">
     
    	<img id="capture_button" src="images/capture.png" />
     
    	<img id="captured_photo" />
     
    </body>

    The ‘captured_photo’ <img> tag will be used to show the captured photo, so it is just empty at the beginning.

    Before proceeding, it is necessary to include the APIBridge JavaScript library to the widget:

    <script language="javascript" type="text/javascript" src="js/apibridge.js"></script>

    Now, in the init() function, that is called when the widget loads, attach the ‘onclick’ event to the above button:

    document.getElementById('capture_button').addEventListener(
      'click',
      takePhoto,
      false
    );

    Now, the interesting part: the takePhoto() method has to call APIBridge, and start the photo capturing. This is done by using the newFileService method, that accepts 3 arguments:

    • the type of file (it can be: APIBridge.NewFileType.Image for photos, APIBridge.NewFileType.Video for video, and APIBridge.NewFileType.Audio for audio files)
    • the onSuccess event handler
    • the onError event handler

    So, the takePhoto() function calls the APIBridge.newFileService method as shown below:

    function takePhoto()
    {
      APIBridge.newFileService(
        APIBridge.NewFileType.Image,
        photoCaptureSuccess,
        photoCaptureError
      );
    }

    Now, what remains to do, is to define the onSuccess and onError event handlers.

    The photoCaptureSuccess() function receives as argument the full path of the new image or, if no image was taken, it just receive NULL.  The following function check if its argument is defined, and then sets the source of ‘captured_photo’ by using the image path.

    function photoCaptureSuccess(photoSource)
    {
      if (photoSource && photoSource.length)
      {
        document.getElementById('captured_photo').src = photoSource;
      }
      else
      {
        alert("No image taken...");
      }
    }

    The error handler receives as argument the Ajax request used to perform the call to APIBridge. In this case, it is enough to display an error message, informing the user that an error occurred:

    function photoCaptureError(ajaxReq)
    {
      alert("Error " + ajaxReq.status);
    }

    Now, all is ready to test the widget. Let’s build and package it as described here, and here it is in action on a real device!

     
    • Jack 4:03 am on October 12, 2010 Permalink

      I have try this code, but i confuse for the “Now, in the init() function, that is called when the widget loads, attach the ‘onclick’ event to the above button:”….anyone can help me?

  • pit 3:13 pm on February 4, 2010 Permalink | Reply
    Tags: ,   

    Symbian now completely open source! 

    The Symbian countdown has ended, and the mystery is finally solved: Symbian is now completely open source!

    What does this mean practically? From the official announcement:

    Any individual or organization can now take, use and modify the code for any purpose, whether that be for a mobile device or for something else entirely.

    And more:

    All 108 packages containing the source code of the Symbian platform can now be downloaded from Symbian’s developer web site (tiny.symbian.org/open), under the terms of the Eclipse Public License and other open source licenses. Also available for download are the complete development kits for creating applications (the Symbian Developer Kit) and mobile devices (the Product Development Kit).

    Even if already announced, this step is huge for the mobile ecosystem, and I could not agree more with the words of Eben Moglen, Founding Director, Software Freedom Law Center:

    Software freedom on mobile hardware is absolutely necessary to the preservation of privacy and the encouragement of innovation in mobile technology, and to protecting the freedom of the Net overall.

    Well done, Symbian!

     
  • pit 5:37 pm on February 3, 2010 Permalink | Reply
    Tags: , , , hello world,   

    Build your first Web Runtime widget with APIBridge 

    This article shows you how to create, compile, build and deploy a Web Runtime widget, that includes the APIBridge plugin developed by Nokia, and available on Forum Nokia website.

    The APIBridge is a Symbian C++ engine that exposes native functionalities to Web Runtime widgets. These functionalities include:

    • Uploading files.
    • Capturing video, image, and audio.
    • Reading files.
    • Resizing images.

    Before starting with the following steps, you have to download APIBridge from Forum Nokia website, and unpack it to a convenient location on your machine.

    Also, to compile and build the whole example, you must get one UID from your SymbianSigned account.

    Step 1. Prepare your widget

    The first step is to develop your own widget, and to package it into the standard WGZ format. You can develop the widget with the tools of your choice.

    In this tutorial, I’ll just build a simple “Hello World” widget with the WRT Plugin for Aptana Studio. You can read a full guide about creating from scratch a simple widget on Forum Nokia Library.

    Using the Aptana Wizard interface, let’s create a new “Nokia Web Runtime Widget”.

    Now, let’s customize the “index.html” file with your Hello World text.

    So, the test widget is ready to be packaged!

    Step 2. Compiling APIBridge source code

    Now, take the folder where you have unpacked APIBridge, and make a copy of its WgzInstaller folder. We’ll use this copy to create the new widget installer.

    Note: to perform this step, you must already have your own UID.

    Now, perform these changes:

    1. Open the group\WgzInstaller.mmp file, and replace the fake UID 0×12345678 with your own
    2. In the src\WgzInstaller.cpp file file, replace the KWidgetInstallerFileName with the actual filename of your packaged widget

    Now all is ready to compile your source code. Go into the group\ folder and, from command line, run:

    bldmake bldfiles
    abld build gcce

    If you don’t get any errors, the APIBridge code shoud have been correctly compiled.

    Step 3. Customize and package

    Now, copy your packaged widget to the content/ folder. Done this, open the /sis/WgzInstaller_template.pkg file and set the appropriate values for these properties:

    • Application name
    • Installation UID
    • Vendor name
    • .wgz file name

    Since we’re building from command line, we also have to tell where makesis can actually find the WgzInstaller.exe file created in the previous step. In this tutorial, I’ve used the S60 5th edition SDK v1.0, so I’ll change this value:

    “$(EPOCROOT)Epoc32\release\$(PLATFORM)\$(TARGET)\WgzInstaller.exe”

    to

    “\S60\devices\S60_5th_Edition_SDK_v1.0\Epoc32\release\gcce\urel\WgzInstaller.exe”

    Now, let’s create the SIS file: from command prompt, go into the sis/ folder and run:

    makesis WgzInstaller_template.pkg

    Your output should be something like this:

    Processing WgzInstaller_template.pkg...
    Created  WgzInstaller_template.sis.

    Step 4. Sign and deploy

    Take the SIS file you’ve created in the previous step, and sign it with your own SymbianSigned certificate:

    signsis WgzInstaller_template.sis WgzInstaller_template_signed.sis your_certificate.cer your_key.key your_password

    Now, your widget is ready! Just send it to your Nokia device, and install. You’ll notice that, during the installation, you’ll be prompted to install both your widget and the APIBridge engine.

    Below you can see the Hello World widget running in all its glory :)

    Thanks go to Leonardo for his precious support! :)

     
  • pit 10:04 am on February 2, 2010 Permalink | Reply
    Tags: lego, n95, rubik,   

    New candidate for the geekiest Symbian app ever! 

    An extraordinary example of creative programming applied to real-world problems :)

    (via Leonardo)

     
  • pit 3:59 pm on February 1, 2010 Permalink | Reply
    Tags: , mistery,   

    The Symbian countdown mistery continues… 

    Can you solve it? :)

     
  • pit 7:05 pm on January 31, 2010 Permalink | Reply
    Tags: , , , , updates, upgrades   

    WordPress update progress and the experience on mobile 

    I’ve just upgraded WordPress to its latest version, and can say without any doubts that its upgrade process is by far the best I’ve seen for any Web-based tools.

    Why I think it’s great? Because you have to perform 2 mouse clicks and wait a couple of seconds, and you can continue working on your WordPress (upgraded) blog without any other hassles.

    Looking at that made me think about the update process of mobile applications.

    In many cases, applications are simply not aware of the availability of updated versions, and so users are supposed to manually check (e.g.: going on the publisher website) for updates. What does this mean? Simple: terrible User Experience (if even we can say that), and in most cases old (and possibly bugged) versions of your applications running everywhere.

    For this reasons, developers started to implement their own “updates-availability-check” systems, letting their applications check for updates and prompt the user about the availability of those. Anyway, this approach has 2 important drawbacks:

    • users must open the application in order to have it check for updates
    • the very same logic (checking for updates, downloading and installing the updated application) is replicated in each application

    Luckily enough, mobile platforms are fast moving toward an integrated approach, based on the concept that updates have to be pushed to the user. Examples of this are iPhone and Maemo, both notifying the user in case of available updates.

    While this is currently the best approach from a UX point of view, the same makes me wonder if a better approach (maybe totally transparent to the user?) could ever be possible, considering all the technology and security concerns of such an approach when talking about mobile devices.

     
c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel