Kuneri bloggy

[Here is the quick link for the list]

It’s essential for every mobile developer to know their target mobile device profiles. This is the only way to ensure effective and reliable development plan and easier porting. That’s also been an issue for us and we often needed to collect technical information for all target devices we aim and up now did that manually combining different resources.

Flash Lite development and porting can be considered as ‘less complicated’ compared to Java and Symbian based platforms. However, that doesn’t change the reality that there is always the need to port. Especially after Nokia introduced S60 3rd edition devices, porting for Flash Lite got little more complicated, compared to S60 2nd edition’s (almost) the same 176×208 display size and specifications for most of the devices. One can claim here that; Flash Lite can scale and fit into different screens easily and that’s why Flash Lite is Flash Lite. Yes, that is true at first sight, however, unfortunately the fact that ‘it can’ doesn’t mean ‘it does’ well. Depending on the application, development will vary, and not everything will be displayed as expected or will perform good when they are scaled. Therefore, the only reasonable solution is to create different versions of the product for different possible screen sizes by defining target devices well and preparing a robust design to ease the pain of porting. To gain more insight about this issue, you can check Dale Rankine’s ‘Quickly create multiple versions of your Flash Lite content‘ article on Adobe web site.

Considering these facts and possible future needs, we prepared a list for developers to have a reference when developing Flash Lite applications. Initially there are only Nokia S60 and Series 40 devices, however, we hope to extend the list further with your help. Please register to our forum, and contribute to Flash mobile device list for developers. There is also performance information for all devices, which will be filled with tests performed by us and other developers.

When you visit the list, you will see some devices are in bold. Bold means that there is a confliction between Adobe and Nokia’s Flash Lite specifications or global knowledge. We hope to clarify these question marks to avoid future misleads for developers. If you happen to have a reliable information about these models, please add your comment on our forum.

We recently got the news that Adobe announced a public beta of Photoshop CS3 together with Device Central. Hopefully this will be a global solution for Flash mobile developers and eliminate further needs in future when things get more complicated with more devices available. However until then, we need clear and reliable information to reduce development risks and reliable marketing.

There is a nice article about Flash Lite, posted by Denise at globeandmail : Hold the phone, Flash is coming!

Software is revolutionizing cell handsets in Asia and Europe, adding fanciful graphics and menus.  Dial a mobile phone subscriber in Japan and your call could set off a display of onscreen fireworks. When signal strength is low, clouds rolls into the picture. A missed call might cause a hot-air balloon to fly across the screen. And when the sun sets, an image of the city skyline changes from daytime to night.

It is funny how one meets different people at different places. I was sitting in my Spanish class and introducing myself in Spanish:”Soy scientifico…” I told that I had researched agile software development. After the class was over, the man next to me started talking to me. He was an experienced project manager in a leading Finnish company and he was seeking new processes to utilize in his current team. We talked for an hour about processes and how to manage a team in an evolving environment.

One thing I was very curious about was the way he had managed one of his teams throughout his years as a project manager. His team consisted of young competent developers and an experienced developer. The project went on well except one hidden problem: the experienced developer was implicitly running the whole developing process i.e. the other developers got used to the fact that they could ask the experienced one to solve the most complex problems. The result was: other developers had not been evolving and improving their competence on problem solving.

The project manager saw this negative effect, so he arranged a transfer for the experienced one to other assignments. Thus, the development team suffered from a major brain leak. Nonetheless, these developers were very motivated towards their job and assignment and they had a very strong team spirit. Every one was ready to work for common purpose: to achieve project goals and deliver an excellent product. The overall result was that the developers managed to build a very satisfying product. In fact, he said that if you would check Finland’s gross domestic product from those years, you could see an unexpected raise, a peak, compared to the usual level.

Summa summarum: it is quite self-explanatory matter that motivated developers form an effective team. However, people think that as a self-explanatory matter, without really thinking on it, really. One should sometimes stop and think what is important if one wants to really succeed. Of course it is true that the programming itself is an important thing as far as software is concerned, but there are still other matters that affect product quality implicitly.

We, as a team in Kuneri, are motivated because we know our aim and what to work for. The goal is clear in our mind and we are evolving day by day, facing with new challenges on our own. We advise everyone to do the same thing: Keep motivated :)

Veli

New tutorial: Creating SIS files for distribution from Adobe mobile and devices developer center. With this tutorial, you can learn how to pack a Flash Lite project with many files, into one Symbian SIS package. There is also a sample ZIP file, which includes tutorial files. Alex offers also a PHP solution instead of PKG, might be handy if you do not want to deal with PKG syntax.

I tested installation on 6680 and N80. It works fine on 6680, except a usability issue on SIS installer, and a small bug in application. On N80, installer problem is not there, but the bug is present less remarkably. Furthermore, there is an unintended (not in the files list) unsigned SIS file for 3rd edition in the sample ZIP package, which of course does not install. None of the problems I mention are important ones.

While installing on 6680, it warns that application may not be compatible with the phone and asks to quit installation. If you are a “next&next” person as I am, you may read this message quickly and press “yes” directly, thinking that the question is if I want to continue, and it may naturally exit the installation. This is a usability issue of Symbian installer in my opinion. It’s weird to put a quit action on left soft key (negative-positive action on a positive key).

There is also a small bug in the application. I think Alex used a small trick to improve playability and performance of the pacman game, and set the quality one level lower. However, quality is not changed back to higher one when you quit, causing remarkably worse display on low resolution screens. So, if you select pacman and quit, quality still stays lower and application displays lower quality screens. After entering and quiting invaders game, it comes back to higher quality.

On N80, I tried to install unsigned SIS, naturally didn’t work. Signed SIS works fine as expected and installs nicely. Bug in the game is not so remarkable after quiting Pacman, due to the high resolution of the display, but still there.

Uninstallation works fine on both models without any problem.

I also looked for possible signing solutions for 3rd edition, however, it’s not mentioned in the tutorial. I think it is the biggest issue on creating installers for 3rd edition and will be a problem for beginners while trying this tutorial. It would worth to mention that point.

As a conclusion, the tutorial is nice, however, doesn’t offer a complete solution for the common Flash Lite installation problem on Symbian platform, especially 3rd edition devices. It also doesn’t come up with a good start-up solution, which would enable users to run the Flash Lite content from menus with a dedicated icon. Users have to use a browser application to execute the content. I do not find that approach formal, usable and practical. But ok for testing purposes, if your application has many files and you do not want to deal with them every time you update. I would still recommend you to check the previous tutorial I posted some weeks ago. This one seems to be the most convenient way to present Flash Lite content for market currently (unfortunately still not a complete solution). I hope Adobe comes with better and complete solution to overcome this problem in near future.

Aniway is very active this month. Check their new article in Adobe’s site : Optimizing your content for OTA (over the air) delivery.

Just like any content distributed this way, Flash Lite content that is distributed OTA needs to be optimized—to squeeze out unnecessary kilobytes and decrease the overall size of the application, and to use best practices in order to get maximum performance out of mobile devices with limited processing power. The smaller the size of the mobile application, the faster it downloads to the device.

Miikka from Aniway posts second part of his Flash Lite developer categorization series: “No Money Involved”. Once again interesting and quite realistic approach. Next part is “Developer with funding”. Thanks Miikka for sharing his experience!

It’s been some time that I am trying to decide the most convenient way to present my FlashLite content. There seems to be 2 primary choices: A bare SWF or an installation package.

To present the product as a SWF file only, is not a very preferable way personally. Although it is simple, it is not secure, not formal, and inefficient; if there are other resource files. However, installation package does not seem to be a great solution also. We are always proud that FlashLite content can be made compatible for many devices without much effort. That might be reasonable, considering the meaning of porting for other platforms (i.e Java Mobile and Symbian). However, how about the portability of installers? Most common one is SIS file; however, if we create a SIS file, unless we show some extra effort and money, it will not be S60 3rd edition compatible. Furthermore, it will not be supported by other platforms than Symbian, and even there will be difficulties among Symbian series (S40, S60…).

So, what could be a good solution for that? There is already a problem of FlashLite supported devices in market, penetration is not that high. If we also limit that by our installers, how will it be possible to distribute our content to widest possible devices? Should we start thinking about all FlashLite enabled devices and try to prepare an installation system seperately for each group?

Meantime, I got lazy, and checked if there are some easy solutions to create my SIS package for my FlashLite content. Here I found this tutorial. Enjoy!

This tutorial will demonstrate how to create a nice packaged Symbian application (with personalized icon in smartphone’s menu) that simply starts the .swf of our Flash project, and then exit. On the web, there are many tutorials about packaging all ours files in a Symbian OS installation file (.sis), but no one that tell us how to “launch” a Flash Lite application.

Dale’s article about quickly creating multiple versions of FlashLite 1.1 content on Adobe’s site.

This article explores issues I came across when porting content between mobile platforms (Nokia Series 60 and Series 40 handsets) and also between devices (mobile to iRiver U10 device). As you’ll see, Flash really gives you a great platform for creating content once and deploying it across various devices with minimal effort.

Great source about the differences between European and American mobile phone use and culture. If you are interested in these markets, it definetely worths to read and pay attention. Also, don’t forget to check comments, you will see many further analysis for different cultures and specific countries.

It could be really nice to see Japan included into this comparison. For Flash Lite developers, maybe the first real market to study and learn.

via biskero

Miikka from Aniway posts an article about development process and content pricing for FlashLite from a realistic point of view. If you are thinking to go for or interested in FlashLite business, check this out.