Well, for a phone it ain't really that amazing, but in the this (at least yet a while) small world called OpenMoko this is actually a break through for me! I've just made the first call from my Neo1973-phone with OpenMoko. Not through the Dialer or anything that fancy, just by executing AT-commands from the terminal.
Read the rest of this entry »
As written earlier, I'm now able to build OpenMoko in a reasonable amount of time due to the purchase of a new computer. I haven't had time to hack that much with OpenMoko in the past week because of a busy week (we made a one-week-project in algebra, so I'm governing Knapsack, Elgamel, group-theory etc. 
), but today I had some time to play.
Read the rest of this entry »
I've just - briefly - tried QPE (Qtopia Phone Edition) on my Neo 1973. I tried both the image on http://www.qtopia.net/modules/devices/openmoko.php and http://buildhost.automated.it/OM2007.2/?M=D and with two different SIM-cards.
Read the rest of this entry »
...is not as straight-forward as I hoped. That's of course because I'm not that experienced at developing to Linux-based environments in C - actually my past consists mainly of Windows-developing with C#. There's quite a huge difference - not only in libraries etc., but also the set-up as such.
Well, the C-coding is slowly returning (I've done some C-coding, but not as much as C#), but I'm still having some trouble setting a proper development environment up. That being said, I really haven't got a whole weekend dedicated for that, but the times I've tried to use MokoMakefil and OE's HelloWorld tutorial wasn't successfully. But that'll come later on, I assure you!
But for now, I'm just developing on my desktop, and then I'll try to get a decen (or just running) environment up and running when the time comes.
With the discussion regarding location-based software as a starting point, I realized that the issue regarding persistence was far from trivial. Of course it's a problem in the matter of making areas (as in a set of locations) persistent, but in general persistence of data structures often seems to be a problem, not just on OpenMoko.
Some optimal data structure might be quite a mess to make persistent, which lead to the selection of another data structure.
Still, I haven't read much about this subject in regards to OpenMoko, but I think remembering something about it uses a Evolution Data Server. Well, it's certainly a subject to investigate further - in particular to location-based reminding which I think is very exciting.
Oh, my Neo 1973 should arrive tomorrow! Yeah!
Neo 1973 comes with (A)GPS. GPS opens a lot of new opportunities - which ones you can decide. Nevertheless, one need to figure out a good way of utilize this in a more general level. The purpose of this post isn't to discuss the Neo 1973 as a specific product, but to lift the considerations regarding location-based software to a higher - and more general - level.
Until now GPS has primary been used for navigation (please don't take this to literal - I know it's been used for a lot of other stuff, too, but this is merely a statement used to widen the mind and open it for new/other approaches), but as several different kinds of products with GPS appear, one has to rethink the whole idea in order to take proper advantage of the fact of GPS (as one might call it).
(As an aside, I would like to refer to OpenMoko to justice the generalization of location-based software: it would be stupid not to have a common location-library - pick an arbitrary name for it of your own choice - instead of every little application should implement general location events on their own.)
Personally I have a couple ideas to location-based software: location-based profiling (mute, non-vibrating among others) and location-based reminders. The first is probably more self-explained than the latter, which is thought of as a when you should be reminded of something on behalf of location instead of time. These ideas has forced me to try to think of location-based software in a generic way.
The first realization is that a generic type of usage is event-driven/-based. Others probably exist, but in this post I'll stay with the event-driven-types.
This would probably be an appropriate time to excuse for my English, and for you to accept my apology and get a cop of black power aka. coffee, tea, or whatever you fancy the most at this particular time.
As earlier mentioned, GPS has primarily been used for navigation. Here the events are whenever the driver should do anything else than just driving straight ahead, e.g. taking a turn, exiting the highway or whatever. Several software products come with ability to make favourite positions, too, and in that way creating a quick route from a favourite location. In the case of navigation, GPS is used intensely every time - assuming that it's mostly used at new routes. The case with position-base software is slightly different - at least in some situations. In particular, I'm thinking of the two examples given earlier with location-base profiles and reminders. Here whole areas has to be saved ("Home", "Work", "School", ...) in such a way that it can be identified and acted upon, i.e. execution of a (system)event.
Two key observations, with a basis in the two examples given, are that it is required - or desired - to identify whenever entering or leaving an area. The solution to this problem depends highly on in which way an area is created. First the term "area" should be defined: a area is a named collection of positions. Then areas can be created in at least the following different ways:
Data-wise it is often less demanding to use the first option, but it requires more computations (it is really enough to save one location and a radius - from that it would be easy to calculate when the current position is inside that area or not). Reversely, the locations in the second option should just be saved in an appropriate data structure and then searched with a good search algorithm (depends of course on the chosen data structure). Both methods (and more?) could be offered, but the crucial question probably is, how big cells/positions are? Maybe several introductory experiments should be made. In addition, distinct users may have distinct needs, so maybe it's best to make the location software so generic, that these and more can all be used. It's certainly a point of interest and one requiring further focus.
Lastly I would, too, like to add another important application: the interface and cooperation with other triggers (such as time). Maybe a user would like to have a reminder when leaving an area, or at least at 3 p.m. This should be made in a natural way, and that requires a significant amount of thoughts leading to a sound architecture.
Well, still looking forward to receive my Neo 1973 so I really can address these issues. In the meanwhile I'll start addressing these problems in an abstract level as done hitherto.
Commercials can be annoying if they distract you or take all the focus, but they finance quite a lot; I can't imagine anyone disagreeing. This is not a discussion whether commercials are entitled to exist or not, but merely a post of one of the consequences that the actually do exist.
ABI Research published for some time ago an article regarding mobile marketing and Google recently published a plan of mobile advertising. With these articles in mind, I started to wonder whether some kind of cooperation with OpenMoko and Google was possible.
Of course not to force someone to receive commercials if they don't want, but instead of using alternative channels with another purpose originally, it could be interesting to make some kind of optimal channel for commercials on mobiles. Clearly it's something trendy right now, and why not try to take advantage of that?
Now I've finally ordered an OpenMoko-phone, a Neo 1973 (Advanced edition) to be specific. I've followed the project from the side for some time now, and five minutes ago I hit the "Confirm"-button.
I'm really looking forward to receive it so I can start to play with it 
I'll of course try to write something about it in this blog.
Mikkel Meyer Andersen |
November 19, 2007 at 15:17 (UTC) |
