How should Mobile projects be to survive?
Wednesday, April 16, 2008
Yesterday we discover that Mowser, the project founded by famous blogger Russell Beattie (and former colleague) was in the deadpool. Russ claimed that he ran out of money and had serious trouble with his finances.
Everyday startups are created and abandoned, but the point in this story is that he could not raise funds to continue with the project. We see almost everyday projects raising a lot of money for nothing, so why an authority in the mobile world cannot pass the first round? Well, honestly I don't know, but from my experience in Amplia, mobile and M2M markets are really really hard. Everybody recognizes the potential but nobody knows what are the killer applications of the mobile business.
Mobile applications are radically different of 'Fixed' applications, and they should have different attributes:
- Mobile applications don't need permanent interaction. You only interact with the application when an event occurs that requires your attention.
- Mobile applications are by the lack of reliability of the wireless networks- error prone. A good mobile application should hide the user of the status of the underlying connection. When the connection comes back, then it should restore the status with the remote services transparently.
- The mobile application must be 'always on'. Again, event driven interactivity.
- Mobile applications must be fasts. The less time the user is interrupted by the mobile device, the better.
- Data traffic shall not be a concern. Help users to know how much will they pay to their operator. The success of RIM comes of the fact that users know in advance how much will they pay for the service.
- If a user is always connected to the network or 'always on', don't make them login again in your service. Use the authentication and authorization services of your operators if possible, or find a smart way to keep the user information linked to his/her device.
What do you think?
The ball and chain of iPhone was not Java: it's Google Android
Monday, November 12, 2007
Sometimes you only need to wait to understand why things happen. When Steve Jobs said 'Java is not worth building in. Nobody uses Java anymore. It's this big heavyweight ball and chain', we were surprised and disappointed because like me a lot of people think that there is still room for Java in the mobile platforms. Of course we have J2ME, but we can do very few things with it. What we need is a full J2SE stack for mobiles. And the iPhone could do it... if Mr. Jobs wants. But he does not want because Java has become the flag of Google to do developers to follow them. He chose to keep Java out of the iPhone to keep a strict control of the platform, to keep Google out of his business.
I have just reviewed what Google Android is, it's architecture and the SDK and I think it's much more than a smart mobile platform: it's a philosophy. Think of what SWT is to the Java User Interfaces and apply it to the Android Architecture. The access to the physical layer has been developed in C/C++ on top the Linux OS, and on top of it there is a pseudo-Java Virtual Machine called Dalvik virtual machine. As they say, "Dalvik has been written so that a device can run multiple VMs efficiently. The Dalvik VM executes files in the Dalvik Executable (.dex) format which is optimized for minimal memory footprint. The VM is register-based, and runs classes compiled by a Java language compiler that have been transformed into the .dex format by the included "dx" tool."
J2ME is very similar in the approach, but what looks new is the tight integration with the OS and the use of Java 5 extensions of the language. J2ME is almost JDK 1.0, but if you read the source code of the samples, you can recognize some coding practices of Java 5. I still don't know if the Dalvik VM can do reflection or annotations, I will need some time to test it.
The access to the physical elements of the mobile device are performed thanks to the set of android.* packages. So, it will be a task of the device manufacturer to migrate the C/C++ libraries layer for their devices. I have tried to find some information about how to certificate that the libraries has been migrated correctly. This was one of the key elements for the success of J2ME on the mobile phones, and should be done the same way.
The Java applications are what they call 'Third party applications'. It's not possible yet to develop or modify the underlying Linux OS and the C/C++ libraries. Again, Java runs in a sandbox -sounds familiar, eh?-.
I will continue playing with it. Just some random thoughts, will Sun Microsystems get some money for the licensing of Dalvik VM? How much? Will J2ME be replaced by the Dalvik VM?
Labels: architecture, development, embedded, google, gphone, iphone, java, linux, mobile
Palm Foleo cancelled just before shipping
Tuesday, September 04, 2007
I was astonished when I read that Palm cancels Foleo just before starting to ship it. The reason sounds like an excuse: '...it has become clear that the right path for Palm is to offer a single, consistent user experience around this new platform[WindRiver] design and a single focus for our platform development efforts.'
There were rumours of delays because buggy software. The product was announced for shipping this summer, but the season was running out and there was not date for the product.
What have happened? Who knows... The Foleo device were going to face a very hard competition with the new low-end laptops. It sounds like they are rethinking the product. Meanwhile, this cancellation has cost to Palm 10 million dollars.
GPay: Google Patent for Mobile micropayments
Monday, September 03, 2007
Today in several RSS feeds I have found the same news: Google has a new patent for mobile micropayments. Micropayments using a cell phone is not new at all. I have seen some projects in Europe, specially the Spanish Mobipay. It's a mature technology, but it's not very successful. There are several reasons but it's not clear why mobile micropayments are not growing. In my opinion:
- The fee is charged directly to the customer. If you buy a Coke in a vending machine and you pay 1€ with a coin, you have to pay 1.10€ with mobile micropayments. So the micropayment is the last option.
- For more expensive goods Credit Cards or Cash are preferred. Why? Again because the Credit Card fee is charged to the seller, not to the customer.
- With mobile micropayments your credit is given by the Mobile Operator. The Mobile Operator needs to cover the risk, and this is an overhead compared to the credit card model (everybody knows how a Credit Card works, isn't?)
Labels: business, enterprise, google, micropayment, mobile
Bad times for J2ME. How the iPhone with Web 2.0 apps can rule in the mobile world
Wednesday, August 22, 2007
The day Steve Jobs said 'Java’s not worth building in. Nobody uses Java anymore. It’s this big heavyweight ball and chain' . Being a Java Zealot as I am, I should find easily a fist full of arguments, but may be he is right.
I have been working in the embedded and mobile world for almost four years in Amplia, and I can tell you that Java is far from being the best option for mobile and embedded development. Even for complex mobile applications I think it's not even an option. There is not a decent implementation of the J2SE for ARM microprocessors, on Linux or Windows CE. There are some implementations out there, but believe me, they are far from the quality standards that Java developers expect. Sun Microsystems realized long time ago that building a J2SE for ARM and embedded OS was hard and expensive and they gave up, abandoning the project.
Of course J2ME it's there. But J2ME was designed for devices with a lot of limitations in term of resources. Devices like mobile phones and embedded hardware. But not for PDAs and the new Smartphones with big screens. Try to build an application with a rich UI with J2ME. It's a nightmare compared to CF.NET for example. J2ME has been very successful for games and simple apps for mobile phones which can gain access to the hardware layer, but nothing else.
But Steve Jobs was not talking about the heavyweight ball and chain of Java because his big memory footprint, slow start up and all that techie stuffs. It's a ball and chain because means a marriage with Sun Microsystems. Steve Jobs would love to have a J2ME virtual machine for the iPhone... if it was for free. But it's not. All devices running J2ME must pay a fee to Sun, no matter if they use it or not. And that's a lot of money. For example, the IBM J9 J2ME implementation for ARM costs $6 per license. Why should Apple pay for it? They have the OS for free -a Symbian license costs between $2.5 and $5-, they have the browser for free -I don't know the license costs of Opera-. So probably Apple can save around $15 per device just using their own dog food. So they said:
1) is it possible to build web applications with HTML and Javascript on Safari? Yes, we just need to allow developers to test easily on Safari. Voila! Safari for Windows!
2) Can we migrate Flash to the iPhone? Yes, and it is easier to port it than a full J2ME stack. Games, Video Streaming and Rich UI apps can be done in Flash too.
3) How many applications today need offline behaviour? Not too much, but less than a few years ago with a rise in the trend. And the device have been designed to be 'always on and connected' to the GSM network and WiFi. The 'offline' behaviour is not so important.
And they decided not to include Java because gave nothing to the business model behind iPhone.
But Mr. Jobs forgot something:
1) Mobile devices (and iPhone too) needs to have access to the hardware to control the low level resources like Bluetooth, GPRS modem, SMS messaging, Wifi connection, Serial ports. A web application cannot access the hardware layer.
2) May be the offline behaviour is not so important, but wireless networks are not as reliable as fixed networks. Offline behaviour from the browser is not mature at all.
So Mr. Jobs and the iPhone needs a piece of software to complete his Masterplan. They need an Embedded Application Server. What? Are you crazy? An application server? In a device? I will explain myself. When we think of an application server, we imagine a J2EE implementation with a plethora of functionality. But this app server is different. Here goes a list of what I think it should implement:
- A small web server to deliver content to the local Safari web browser.
- A scripting language to write server side code. Of course this dynamic content should only be served to the local Safari web browser.
- Massive Multithreading is not a must (it's all local).
- A permanent storage in the device for offline operation.
- Management of the low level resources of the device.
- Some kind of queuing system for asynchronous operations between the device and the remote elements.
- A synchronization service between local storage and remote storage.
This embedded application server should implement a scripting language. Why scripting? Because the logic to implement in a device must be simple by definition. The really complex stuff is the management of the hardware layer, and that's should be implemented in C/C++ and be very restrictive regarding the access of applications to this layer.
There are already some solutions out there in the embedded world but most of them focus on the Synchronization service when the really hard stuff is to control the hardware layer.
Labels: architecture, designs, embedded, enterprise, iphone, java, mobile
Ultra Mobile Devices war is coming
Thursday, June 07, 2007
Last week Palm announced a new Ultra Mobile Device (UMD) called 'Foleo'. This week Via has announced a new UMD reference design called Nanobook and Asus has unveiled an 3ePC, ultra low cost laptop . They are different races: Foleo is ARM-based with a limited amount of memory, Nanobook and 3ePC are x86-based. Nanobook uses VIA processors and 3ePC will use the new Tolopai Intel's SoC. There are big differerences in memory (Foleo 256Mb, Nanobook 1Gb and 3ePC 512Mb) but not in storage and communication cababilities (all of them will have several gigs of Flash storage) and Wifi. A note to mention about the design is the awful design of the Nanobook, looking like a 80's alarm clock and not like a 21st century toy. But the most significant differences are pricing: surprinsingly the most expensive is Foleo (600$), Nanobook is 600$ too and 3ePC is 200$. 200$ that's really cheap!
It's obvious that a new wave of portable devices is coming, and all of them have something in common: they will have to run some kind of Linux Desktop distribution due to the limitations in processing power - Windows XP and of course Vista are very resource consuming- and fat client software are not a good solution for them. So it seems web applications and services will push these devices.
I don't know if one of these devices is for me, but road warriors and backberry addicts probably will love it.
Labels: enterprise, linux, mobile
Meraki: Mesh networks can kill Wimax
Thursday, April 19, 2007
One of the most interesting technologies to come are mesh networks. In Amplia we are making some prospects on these technology applied to the M2M (machine to machine) communication. Zigbee fits perfectly for small amount of data, but it's not good when dealing with mobile communications (PDAs, laptops, MP3 players... anything interactive and portable).
The only real ubiquitous networks today are the mobile operators networks. GPRS has an acceptable deployment, closer to 100% of the population in developed countries, but 3G technologies are still far from being everywhere. And probably they will never replace the GSM/GPRS in some areas. 3G networks let the users enjoy of the "mobile experience", providing connectivity anywhere. The problem? The concept of flat fee is out of the scope of the mobile operators, and they charge per use (ok, they give flat fee with a traffic cap). This means that mobile operators cannot attract to the mass of users that use the Internet to share media content, 80% of the Internet traffic in Spain, for example. They only attract business users.
A couple of years ago, Wimax looked like the perfect technology for mobile operators (or alternative operators) to reach out the average Internet user. The deployment was cheaper because of the operation range of the stations and the speed of communication was higher than 802.11G. But we are in 2007 and Wimax has not exploded. Why? There are several reasons:
1) it seems that the deployment of the network is not so cheap,
2) Wimax was sold as a replacement of Wifi, but actually is a replacement for Cable and DSL, very mature technologies.
3) Wimax hardware is not very popular, and it's expensive compared to DSL+Wifi solutions, for example.
4) The spectrum limits the amount of data guaranteed per users. So, depending the density of the area, the size of the cell can be like the size of standard mobile networks.
So basically if you want to deploy a Wimax network in metropolitan areas, you will have to compete with Mobile Operators and Internet Service Providers. The niche where Wimax can beat other technologies are:
- non very populated flat areas, here Wimax is a winner.
- metropolitan areas with flat-fee of traffic data, for mobile users.
I read in Linux devices that Meraki was selling a Wifi mesh router for less than 50$ (37€). There are also discounts per volume. We have tested mesh networking with OpenWRT and it works, the problem was the cost of the devices. The cheapest one was three times the cost of the Meraki's gadget. If we take the budget of the Wimax base station, we can buy 2000 routers, and we still have 20000$ to pay the installation of the devices (10$ per device... a bit low). If we deploy the network in a grid of 5Km x 4Km, we can cover 20 sq-Km, assuming a distance between nodes of 100meters. That's 4-5 times the area covered of by the Wimax base station!
May be I'm making some naïve assumptions, but the point is: may be Wimax is dead because Mesh Networks are cheaper to deploy. Wimax follows the 'mobile operator' approach: complex centralized infrastructure. Mesh networks follows the opposite approach: simple distributed infrastructure. In the wired world, internet has proven that the distributed approach is the right one. Google is the perfect example of the success based upon the concept of distributed computing. And do you know who is backing up Meraki? Google, of course...
Mobile operators and ISPs, Google is going to take over your business soon!
Labels: architecture, enterprise, google, M2M, mesh, mobile, wimax
New Amplia's Blog about Wireless M2M
Friday, February 09, 2007
Now that the 3GSM is going to start next week in Barcelona, we have launched our new Wireless M2M Blog. We hope to contribute with some interesting stuff regarding M2M business and services.
Rafael Morillo (our Business Development Manager) will be the main contributor to the Blog, but I hope to help him with my techie thoughts about the M2M.
Labels: enterprise, M2M, mangement, mobile


