This Site & Me
I'm a technologist, mobile specialist, experienced software developer, author, public speaker & an SAP employee. My thoughts, ideas, rants, comments & most of the code you'll find here are my own. Feel free to use any of this, but be sure to identify the source.
Topics You'll Find Here
This site contains content on a bunch of different topics including Mobile, Mobile Development, IBM Lotus Domino and other topics that strike my fancy. I've written a couple of mobile development books, so mobile and mobile development tend to dominate.
- Category: Mobile Development
- Published on Tuesday, 26 January 2010 08:00
As I mentioned last week, I’d been trying to build an Android application for my rich client session at Lotusphere 2010 (AD114). I got off to a very late start, but with the right resources I thought I could throw something together to show in my session.
I took the XML-based web service I created for the BlackBerry Java and Windows Mobile examples (they both provide native support for XML-based web services) and created a new one that used Representative State Transfer (REST) to process the request and return some JSON with the results. The agent is working great, I’ll write about it in a little while.
I created a Android Java project in Eclipse and started coding through my sample application, reading a couple of books as I went. I got the main application working, got the search box and the button that called the service working and was finally able to connect to the local Domino server to request the data (read about that here). As I tried to figure out the Android ListView widget, my application crashed and I just couldn’t get any further. I poked and prodded in Eclipse and the simulator and just couldn’t get anywhere. Whenever I load the application, I get the following screen:
It’s something in the startup of the application, but it’s not telling me anything about the source of the problem. On the flight home, I read more about the LogCat view in Eclipse that would allow me to see what Android is saying when the application crashes. It turns out that there’s an uncaught exception being generated when the application starts. Here’s the relevant log lines:
At least I know what’s happening now – all I need to do now is figure out the source of the problem. I’m disturbed that I’m not getting more information in the UI about the problem. On the BlackBerry platform, you’d get an error message identifying that there is an uncaught exception and listing the exception that should be caught. If I had that information, I think I could find this problem pretty quickly.
OK, so I dug into the code and found the problem. I was using EditText and TextView widgets to create some of the UI. EditText widgets to accept user input and TextView widgets to display some text on the screen. When playing around with some things, I’d inadvertently cast the TextView as an EditText object (that happens some time when you’re copying and modifying code). As soon as I changed the cast to TextView, the application is running again. Woohoo!
The line containing the information I needed is here:
Next step is to figure out how to use an Android ListView widget to display the array of names that is returned by the Domino server. Stay tuned…
- Category: Miscellaneous
- Published on Saturday, 23 January 2010 07:45
OK, so I work for AT&T now and that focuses me more regularly on AT&T-related topics, but I'm trying to write about them only when they apply to a wider mobility or telecommunications topic. I was poking around today and discovered AT&T's Public Policy Blog.
While probably not very interesting to people all around the world, but I did find some interesting articles about AT&T's response to the FCC regarding Network Neutrality. This topic has fascinated me for a while and the Jury's out (as far as I'm concerned) whether the results of this whole argument is going to be a good thing or a bad thing for me (us). I know I want to be able to do whatever I want with the network pipe my provider provides me and at the same time I understand the network provider's concerns about how their network is being used. Ultimately it should be the consumer's who's rights are protected (I know, I'm baised) but the result if we have our way will be that the network providers will ultimately charge us more for what we get - just to protect their investments in network upgrades and management hardware so we can have what we want.
Anyway, the site has several exhibits AT&T sumitted along with its response to the FCC that highlight some of the background details and outline what many think will happen depending on how this argument goes. I'm printing out hundreds of pages from the articles right now to read on an airplane in the next couple of weeks. i'll probably have more to say once I've read through all of them. Stay tuned.
- Category: IBM Lotus Domino
- Published on Friday, 22 January 2010 12:43
As promised, the final database and project files for my AD114 session from Lotusphere 2010 have been posted to the files area of the site.The available files are:
I spent some time on the plane ride home reading through another Android development book and got some new insights to the problems I was having with the demo. I will spend some time working on that project in the next few weeks (in between the move to NC and my real job) and hope to have something posted by the end of February. Bug me if you don't see it by then.
I'll start working on the iPhone version of the same app - with plans (as they are) to have something posted by the end of March.
Several people have sent me emails about some broken links on the site. I implemented a commercial SEF plug-in for Joomla! and apparently even though they say old links will continue to work, they apparently don't. Thanks for the feedback, I'll try to fix them ASAP.
- Category: Mobile Development
- Published on Wednesday, 20 January 2010 06:35
I had to abandon my plans for demonstrating an Android application talking to a Domino Web Service for my session this morning. I'm disappointed. I spent a lot of time learning it and working through the kinks. I got it to a point where I was able to access the Domino service and was getting data back when all of the sudden the application just stopped working on the emulator. I'm going to keep at it and write something I can put up here for everyone to look at, but I just won't be demonstrating it here at Lotusphere 2010. I got too sick before the holidays (still not recovered yet) and just didn't have the time to do this right.
What I did to support this application platform was create a new service to use for iPhone and Android. Windows Mobile and the BlackBerry can use the XML-Based Web Service that Domino supports natively, and that's what I'm going to show in the session. But for other platforms (the iPhone and Android don't support XML-Based Web Services natively) I created a service that uses REST (Representative State Transfer) to process the data. It works really well and can also be used in a Widget using XMLHTTPRequest (which I'll show here as well some day).
So, expect to see the new RESTful Domino agent documented here soon followed by the Android application, a BlackBerry Widget and, now that I have a MacBook to play with for about 90 days, an iPhone version as well. This is going to be fun. I'll be moving right in the middle of all of this, so I don't know when I'll get it all done.
- Category: Mobile Development
- Published on Tuesday, 19 January 2010 13:25
In preparation for my presentation at Lotusphere tomorrow, I've been beating my head against a problem and finally found a very simple solution. I thought I'd share. I'm trying to add an Android example to my rich client session and because I've been sick, I didn't get to work on this until this week. Nothing like last minute coding, eh?
Anyway, I have the Domino server running on my laptop and I've been trying to connect to it from the Android Emulator for about a day now. You can't use localhost, because localhost on a mobile device (whether it be an actual device or an emulator) points to the local device. The emulator therefore doesn't know about the local laptop through that reference (which is what you'd do to do any local testing laptop app to laptop app).
The orginal web site where I found this information is no longer up, so here's the details:
For an Android application running on the Android Emulator, to allow the application to access network resources running on the system running the emulator use the IP address 10.0.2.2.
- Category: Mobile Development
- Published on Tuesday, 19 January 2010 05:26
I’m going to try to coin a new phrase this afternoon in my Browser Development tricks session at Lotusphere 2010. I wanted to write about it here first, just in case it takes off and I get credit for the idea . The term is "Battery Bit" or, as I decided to try out early this morning, ‘Battery Bit Time.’ I’ll explain what it means in a little bit (no pun intended).
I’ve been doing a lot of analysis of the wireless development space and have noticed a couple of trends. The biggest one is that developers have begun (mostly because of the iPhone) to completely disregard the network and the limited capabilities of mobile devices when they build their applications – especially their mobile web applications. We’re dealing with small devices with limited processing capacity, limited memory and limited battery life, and developers are regularly building apps that no longer take that into consideration. They’re treating these smartphones like they’re desktop computers and that’s causing problems for everyone.
AT&T is getting hammered by its customers and by the press for its network problems, but honestly (as an AT&T employee it’s very important for me to point out here that the statements made in this post are my personal opinion and in no way reflect or represent the thoughts or opinions of my employer) it’s the users & applications and their complete disregard for the network that are causing the problem. The network is fine – and recent independent tests have concluded that it’s faster and better than its competitors; it’s how the network is being used that’s creating all of the problems. I hope to get some time in the next couple of weeks to write more about this because I think I have some interesting insights into this – but we’ll see if I can carve out the time to do that writing…
OK, now back to Battery Bit Time. As Mike Lazaridis (the founder of RIM) says, there’s no way to get around Physics. Every bit of data that is delivered to and processed by a mobile device has an impact on the device battery life, the wireless network and the application user. Let’s dig into this.
Every single bit (or byte, depending on how you look at this) of data transmitted to and/or from a mobile device affects the battery life for the device. If you send less data, you’ll likely get better battery life out of your device. It’s simple Physics (or as my father would say “it’s Basic Physics”), every amount of work the device is asked to perform drains the battery. There’s just no way around it. So, what happened to the days where mobile developers took that into account with their applications? It’s gone. The iPhone is basically a small desktop device – even its browser refuses to identify itself as a mobile browser. It’s regularly downloading full, desktop versions of web sites across a wireless network that shouldn’t be processing so much data. Developers should always (and yes, I do mean always) send as little data as needed across the wireless network to provide the needed functionality for the application. No more than needed. There’s no need for Flash, images, cool transitions or other glitz – just send the data the user needs and nothing else. Mobile web sites should be text-based, nothing more. If you do this Developers, you’ll allow your users, through the simple application of Physics, to achieve better (longer) battery life for their mobile devices. Since Apple has decided we’re not worthy of being able to swap out batteries (which all other mobile devices do) when we run out of power this becomes even more important for iPhone users.
As with every bit of data transmitted to/from a mobile device, every bit processed by the mobile device application (whether it be a browser or custom application) has an effect on the user. Every bit of work done by the processor further drains the battery. There’s no way around the Physics of this. It’s why as much processing as possible should be done by the back-end server, minimizing the work done by the client-side processor. When building mobile web sites or rich client applications, as cool as the technologies are that allow you to crunch data locally and create a very cool and compelling visual experience for your applications – it’s not needed on a mobile device and does nothing but drain the battery and decrease the responsiveness of the application for the user. See my article about the BlackBerry Developer Conference application for more on this topic.
Taking this even further, every bit of data transmitted to/from a mobile device and every bit processed by the mobile device application increases the amount of time it takes to display the data on the screen for the user to access/act upon. Mobile devices and mobile applications provide immediacy – give me access to the things I need access to when I need access to them. Right? By building these complicated applications – web applications with all this funky, dynamic rich content or native applications with all of these fancy visual effects and transitions does nothing but drain the battery, make the processor do more work and delays the display of the data the mobile user is interested in seeing.
The BlackBerry Developer Conference application drove me crazy because of how long it made me wait to see the data I wanted just because they wanted to have a custom screen background image for every page and a cool fade transition between menu item selections. It’s ridiculous. These are mobile devices with limited processing capability, limited battery capacity and limited network bandwidth available to it. Treat the mobile device it’s a mobile device – give the users access to the information or data they need and do nothing more. Just because you can do all of these fancy screens, transitions and so on doesn’t mean you should when you’re dealing with a mobile device. Those types of things are cool for desktop browsers where you have relatively unlimited processing power and much bulkier networks, but they just don’t belong on wireless apps.
If needed, one of the things the BlackBerry does that no other platform does (that I know of) is set an HTTP Header called ‘Via’ that identifies to the target server what connection was used to request the data. Using this, a developer could determine that the connection was made over a Wi-Fi network connection (the Via header isn’t sent when connecting over a Wi-Fi connection) and send a richer version of a web site or an application's data when it knows it has a faster connection available to it. There’s still the problem with processing and rendering time, but it does give the developer more options.
The wireless carriers are in the process of beefing up their networks (4G’s coming soon) but at the same time, mobile devices are getting bigger processors and more memory (not more battery life sadly). Did you see that LG announced a smartphone recently with a 1 GHz processor? Ginormous processing capacity – shouldn’t be used unless absolutely needed.
Battery Bit Time – The impact that the decisions Developers make have on mobile users and wireless network providers. More bits (either processed or delivered) affects battery life and the amount of time the user waits to see the data they want to see.
Even though we’ll soon have almost unlimited processing capacity and network bandwidth availability doesn’t mean that it should be used the way it’s being used. If developers start taking this into account and get back to building mobile applications for mobile devices (instead of building desktop applications for mobile devices), then all of us will be much happier. We’ll be able to use our devices for longer periods without recharging, we’ll think our applications are more responsive and easier to use, and we’ll probably stop complaining about our wireless network providers since there will now be more room for more users and more application data across their networks.
If you get a chance, swing by my session this afternoon, it’s in Swan 5-6 at 3:30 (I’d originally reported it was at 3:00 PM – that was an error).