Kategoria: ohjelmointi (20 viimeisintä)

Huom: kirjoituksessa ei puhuta Finvoicen validiudesta itse XML-spesifikaation kanssa, vaan laajemmin XML-määritysten ja hyvien tapojen mukaisesti. Kun jo tuolla eräs ehti viilata pilkkua :) Toki Finvoicen tuotokset menevät XML-parserista läpi, mutta ne eivät ole "hengen mukaisia."

Vilkaisin taas Finvoicen speksejä, kun pitäisi toteuttaa laskun tulostus sitä kautta. Jo vuosia sitten kritisoin tuota ja kyselin tekijöiltä miksi ihmeessä asiat on tehty aivan päin mäntyä. Vastaus oli "tuli vähän kiire." En tajua miten kiire selittää sen, ettei otettu edes perusasioita osaavia ihmisiä tekemään määrittelyä.

Ne, jotka eivät ole Finvoiceen tutustuneet, se on XML-muotoisten laskutietojen välitykseen tarkoitettu standardi. XML taas on rakenteellisten tietojen välitykseen tarkoitettu kieli. Huomatkaa sana "rakenteellisten." Tätä meinaan Finvoicen speksaajat eivät ymmärtäneet.

Normaalisti, jos määriteltäisi vaikkapa katuosoite, sille voidaan antaa täginimi StreetName. Tämä voidaan sitten laittaa vaikkapa Sender-tägin alle, tai Recipient, tai minkä vain. Tiedetään aina, että tuossa on osoite. Miten tekivät Finvoicen speksaajat? Unohtivat kokonaan, että kyse on rakenteellisesta ja tekivät useita eri tägejä osoitteelle. Löytyy SellerStreetName ja tietysti erikseen BuyerStreetName, puhumattakaan DeliveryStreetName:sta. Eli rikottiin XML:n perusidea. Nämä tägit laitetaan tietysti esimerkiksi DeliveryPostalAddressDetails-tägin alle, joka on DeliveryPartyDetails-tägin alla.

Eli siis oikea tapa olisi tämä:

<Seller>
  <Address>
    <StreetName>Koulukatu 1</StreetName>
  </Address>
</Seller>

Onko tuota vaikea lukea ja ymmärtää, että tuo on myyjän katuosoite? Ei. Mutta Finvoicessa asia tehdään näin:

<SellerPartyDetails>
<SellerPostalAddressDetails>
<SellerStreetName>Koulukatu 1</SellerStreetName>
</SellerPostalAddressDetails>
</SellerPartyDetails>

Tässä siis käytetään turhan pitkiä tägejä, ei hyväksikäytetä XML:n sisäänrakennettua rakenteellisuuta eikä anneta mahdollisuutta määrittää suoraan, että StreetName:lla pitää olla tietty esitysmuoto. Tehdään sitten kolme esitysmuotomääritystä ja yritetään muistaa päivittää kaikki kolme, kun muutoksia tulee.

Mitä tämä sitten tarkoittaa? Sitä, että jos haluat jotenkin käyttää osoitetietoja, sinun pitää määritellä asioita moneen kertaan. Sen sijaan, että tietäisit StreetNamen olevan aina katuosoite, pitää nyt määrittää kolme tägiä, jotka ovat katuosoite.

Samoin jatkuva Seller/Buyer/Delivery-alkuosien toitotus on turhaa. Se vain aiheuttaa ylimääräistä tietoliikennettä ja sotkee tiedonkäsittelyä. Oletan, että nämä on haluttu siksi, että ihminen voisi tietoja lukea. Mutta se ei ole tarpeen, sillä ihminen osaa lukea rakenteellista tietoa, kunhan se esitetään vaikkapa sisennettynä. Josta pääsemmekin seuraavaan ongelmaan.

Sisennyksiä ei saa tehdä! Speksi sanoo selvästi: "Jokaisen rivin pitää alkaa "<"-merkillä ja päättyä ">"-merkkiin." Miksi ihmeessä? XML-parserit osaavat kyllä lukea oikeamuotoista XML:ää. Taasko halutaan, että ihminen voi lukea tiedostoa suoraan? Sitten voi käyttää työkalua, joka muotoilee sen näin, jos halutaan.

Myöskin merkistö on pakotettu: "Finvoice-sanomilla käytetään ISO-8859-15-merkistöä." Eli en voi määritellä kyrillisillä merkeillä tietoja, en kanjeilla, en mitenkään. Miksen? Ei sillä että itse heti tarvitsisin, mutta koko maailma ei pyöri tuon merkistön ympärillä. XML-parserit osaavat kyllä lukea eri merkistöjä ongelmitta. Eivätkö tekijät osaa?

Lukuarvot pitää myös esittää XML-määritysten vastaisina. XML-serialisoinnissa käytetään yleisesti lukuarvoissa pistettä desimaalierottimena. Finvoice vaatii pilkun. Myöskin desimaalimäärät on pakotettu, ihan vain "jotta verkkopankissa e-laskusta voidaan muodostaa maksuehdotus." Pankin järjestelmätkö eivät osaa lukea standardimukaista numerotietoa, ainoastaan tietyllä tavalla määritettyä? Toteutettiin kokonainen Finvoice-palikka, muttei osattaisi tehdä asioita oikein?

Laskurivejä voi myös olla monenlaisia. Laskurivillä ei välttämättä tarvitse olla edes mitään laskurivitietoja! Kaikki ovat silti InvoiceRow. Miksei näitä voitu tehdä omilla tägeillään? "Laskurivi" voi olla vaikkapa vapaamuotoista tekstiä tai välisumma. Ei näin.

Myöskin 2.0-esimerkkitiedostossa on paljon kohtia, joista ei soveltamisohjeessa puhuta mitään. Pitää siis lukea skeematiedostoa ja muita dokumentteja ja arpoa, sen sijaan, että olisi tehty kunnon dokumentaatio.

Miksi meillä on mm EpiBfiPartyDetails sekä EpiBeneficiaryPartyDetails, jotka molemmat kertovat samoista tiedoista?

Miksi esimerkissä on 0 % ALVilla 622,68 euron summa 1500 eurosta? Kopypaste toiminut...

Viitenumeron pitää olla tämän speksin mukaan joko eurooppalainen vaihtelevanpituuksinen tai SPYn mukainen, mutta väkisin 20 numeroa. Harva käyttää 20-numeroisia viitteitä, mutta nyt niihin on sitten pakko laittaa etunollat?

EpiCharge-tägin sisällön pituus pitää olla nolla. Esimerkissä sillä on sisältöä, eli esimerkkilasku ei ole validi. Myöskin esimerkkilasku on kotimaan lasku, silti maksuehto on SEPAn mukainen SLEV eikä kotimainen SHA. Tietenkään en dokumentaatiosta löytänyt tarkemmin tietoa mitä nämä SHA/OUR/SLEV/BEN tarkoittavat, mutta sellaisia arvoja sinne voi laittaa. Ja kuka ihme keksi tägin EpiDateOptionDate?

Pikku huvituksena oli myös yksikköesimerkkinä oleva kwh/h...

Huvittavaa on myös esimerkkilaskussa oleva teksti: "Tavoitteena on, että Finvoice-laskumallia käyttävät yritykset voivat hyödyntää laskun konekielisesti käsiteltäviä tietoja suoraan omissa taloushallinnon järjestelmissä ilman ylimääräisiä muunnoksia. Yhteisestä mallista hyötyy kaikki osapuolet." Niin, miten tästä nyt sitten ilman ylimääräisiä muunnoksia käytetään tietoja hyväksi, kun tiedot on ripoteltu huonosti tägitettyinä, speksinvastaisilla lukuarvoilla ja käytetään yhtä tägiä osoittamaan laskurivejä, seliterivejä ja välisummia? Tämä vain vaikeuttaa tietojen käsittelyä suoraan, ilman muunnoksia. Mutta onko porukassa ketään, joka tämän ymmärtäisi? Ei.

Toki voisi kuvitella, että kun kerran alunperin tehtiin väärin, pakko jatkaa niin. Ei ole. Nyt kun kerran tuli versio 2.0, miksei tähän korjattu asioita? Kuitenkin joudutaan muuttamaan laskun muodostamista ja lukemista, joten samalla vaivalla olisi korjattu nämä asiat ja oikeasti tehty yleismaailmallinen standardi. Nyt tyydyttiin laajentamaan olemassaolevaa ja tekemään asiat vieläkin päin mäntyä. Ja näin varmasti jatkossakin.

Tässä vain taas muutama asia, joihin törmäsin heti määritystä selatessani. Enemmänkin löytyisi, jos kaivaisi. Ja pakko kai on, kun muuten ei saa toteutettua määritystä. Nyt vain pitää muistaa pakottaa XML-tulostus juuri oikeanlaiseksi, kun Pankkiyhdistyksen väki ei osaa muuten lukea tietoja. XML-parserit kyllä osaisivat ilman mitään ongelmia.

Hei Pankkiyhdistys! Ensi kerralla kun teette jotain tällaista, ottakaa vaikka minut konsultoimaan asiassa. Voin vaikka tulla ilmaiseksi niin ei tarvitse sitten tuhlata aikaa puolivillaisten sähellysten kanssa touhuamiseen. Säästän joka tapauksessa aikaa ja rahaa sillä. Kiitos!

Since Microsoft released the Windows Phone 8 SDK, I've had some problems. First, the emulator requires Hyper-V and SLAT support, which is not available on my trusty old Latitude D830. And I'm sure there are lots of people that don't have the newest generation CPUs in their machines. That means they can't test their apps on the emulator. Naturally on device works, but that's not always the best way.

Another problem was pointed out by a friend: there are lots of developers that have done apps for iOS and might want to port those to WP8. They can't just start Windows on Parallels and use the emulator there. VMware supports SLAT virtualization (at least on Windows, not sure about OS X), so it should be possible to run Windows 8 under VMware and the emulator would work.

Personally I run VMware virtual machines on my desktop and if I install the Hyper-V role, I can't run VMware. This is a problem. So I either have to reboot every time I want to run the emulator or install another Windows 8 in a virtual machine and run the emulator there. Both are cumbersome.

I kinda understand why Microsoft made it this way. They have a strong virtualization platform and as we've seen with iOS and Symbian emulators, it's not the same running the app compiled to x86 and on top of another OS. There are problems that are not on the device or that don't appear on the emulator. It's much better to run the actual ROM image that is on the device. But to require SLAT and disallow other virtualization at the same time is not nice.

Hoping MS could fix this problem, but I think it might not happen. I've been thinking about getting a new laptop for some time and this is one more reason for it. But since my old machine works so well and the only thing I'm needing is basically more memory, I haven't done it yet. Maybe it's time.

It'd help if Nokia would send a Lumia 920 and Microsoft would send a Surface... ;)

I wanted to update my skills since I haven't done much web due to my studies. So I decided I'd update Telkussa to the newest technologies. It was made with ASP.NET MVC 2, used Microsoft's AJAX libraries for data handling and client side templating etc. It works very well and is very lightweight, compared to other popular TV sites.

So, the point was to update it to ASP.NET MVC 4. Since Microsoft has been going towards jQuery for a while, they don't really support their client side templating engine anymore. They recommended jQuery templating. Which is obsolete nowadays, it seems. The next big thing is JsRender.

JsRender looked nice, so I converted the templates for it. Went smoothly, the syntax is simple and there are some examples that tell you how to use it. No problem here!

I also wanted to try out the new WebApiController, which helps in creating REST services. Before I used Microsoft's AJAX thingies that created JS code to use web services. No more, now it's nice and RESTful. So I learned that one. Must do some more work with it still, though. One thing I miss is the simplicity: before I just had to include a server-generated script and I could just call Telkussa.SetFavorite(id) and not do all this $.ajax(...) stuff. Yes, I can make a function that does it for me, but it'd be nice to get it ready-made. Maybe I'll make a patch for ASP.NET MVC someday...

I used Entity Framework for the previous version too but now I wanted to try code first. It's a lot nicer to just create the classes for the database tables and let the system determine the links between them. So simple and clean! So now I don't need any designer stuff for this either.

In the RSS part I got to test LINQ-to-XML, which are these X-classes (XDocument, XElement etc). They're so cool in creating documents, compared to XmlDocument etc. Or what do you say about this:

var res = (from x in ctx.Programs where x.channel == chan && x.stop >= now && x.start > DateTime.Today
	orderby x.start select x).Take(8).ToArray();

doc = new XDocument(
	new XElement("rss", new XAttribute("version", "2.0"),
		new XElement("channel",
			new XElement("title", "Telkussa: " + channame),
			new XElement("description", "TV-ohjelmat nyt"),
			new XElement("link", "http://telkussa.fi/"),
			new XElement("ttl", "60"),
			new XElement("copyright", "Tokavuh Technologies oy"),
			new XElement("webMaster", "info@telkussa.fi"),
			(from x in res select
				 new XElement("item",
					 new XElement("title", String.Format("{0:HH'.'mm} {1}", x.start, x.name)),
					 new XElement("description", x.description),
					 new XElement("pubDate", x.start.ToUniversalTime().ToString("r")),
					 new XElement("link", String.Format("http://telkussa.fi/p/{0:x}", x.id))
					 )).Take(8)
			)
		)
	);

(Yes, I know there are some nasty string concatenations, I'll get to them later :)

The main point here is: the resulting XML structure can be shown in the code and you only need one statement for the whole RSS! First I get the programs from the database. Yes, I could've put it inline too, but it's a bit messy. And if you're wondering why I used ToArray(), it's because you can't create anything but classes with default constructors from LINQ in this case. So I had to take the data as an array and then I could create the XElements from the data.

I like this a lot. It's self-documenting and simple. No more adding children to this and that and keeping track of elements in variables.

All this took me a couple of hours and now I'm back on track with the newest things in ASP.NET field. Kinda. I'm sure there are many things still to (re)learn, but it's a good start. Nice to have a project that can be upgraded and used for learning purposes.

(Note: the public site is still the old one, so no point in checking out the JsRender things from there. I'll put the new one up when I'm sure everything works and I won't mess up the mobile clients etc. It probably already works, and even better than before, but still checking...)

CoreGraphics Log Jam

A good (even old, but still valid) point on what I'm currently angry about. Apple doesn't want to tell the developers what's wrong! In the case of the article, at least now the debugger shows the errors in the debug console, but it doesn't really help.

For example: I load a PNG file from the net and try to use its data (CGContextDrawImage). I get the file, I get the raw data and also sometimes the data is broken. So I get an error in the console. Gee whiz, that's nice. I, as a developer, get an error. But the application DOES NOT! So I can't do anything about it since I don't know the data is broken! I have searched all around and there are always these questions "I get this and that error, how do I check the error" and all answers tell the developer that his values are wrong and they have to check them themselves, or use hardcoded things.

Who in their right mind thought that it would be ok to build a whole graphics API without error reporting to the application itself? Some methods do at least return NULL when something's wrong, but that doesn't help much. Especially when I'm using a function that will decode PNG, determine it's broken and still return garbled data without any error messages to the application!

So, am I just supposed to decode the PNG myself/via other functions, determine it's not broken and then decode it via Quartz 2D again? Sure. Nice. Very fast and convenient on a mobile device.

Sheesh. I thought I'd seen everything Apple has to offer. But I'm still just beginning... Apple, get a grip! We aren't all some fanbois that will take anything from you!

Hardware

Mango supports a gyroscope, but it is optional. The reason for this is that all current phones will support Mango, but they don't have gyros. All new devices should have a gyro. Also support for another SoC was added. Otherwise the requirements are the same as they were for 7.0

In the API front there are new HW APIs: access to camera, motion sensor, compass and gyro.

The camera can be accessed via two APIs: PhotoCamera API supports HQ photos, flash/focus modes etc. Webcam API allows recording video and audio. The former works with a pull model and the latter with a push model.

Compass is available on some pre-Mango phones, but not all. It works if it works, like usual. With my iPhone and Google Maps I usually get an error that's like 30 degrees. So it's useless. I probably should use it only in some deep forest?

Motion Sensor is a virtual sensor that combines gyro, compass and accelerometer. It's more accurate, faster in response and has low drift. it can also disambiguate motion types and has fall-back if there is no gyro in the device. Microsoft recommends using Motion Sensor when available. If you don't have a compass, the API does not work and you should use accelerometer directly.

The OS checks if calibration is needed, the application should show a UI for it. There is a reference implementation that can be copy&pasted directly.

Software

Mango runs Silverlight 4. No breaking changes for apps that work with 7.0. Implicit styles, RichTextBox, ViewBox, more touch events (tap, double tap). If you recompile the app for Mango, there are some changes that have to be taken into account, like WebClient (returns in the thread it was called in, not in UI thread) and background running.

Sockets, Clipboard, IME, IE9 Browser, VideoBrush.

Performance: Gen GC means much faster garbage collecting and less lag, Input Thread means better touch input since it's different from the UI thread, Working set, Profiler tool is available with the SDK. Don't profile the emulator, it's naturally useless. And you can't profile 7.0 apps.

Sockets support TCP, UDP with uni/multicast on wifi. Connection manager control overrides and/or sets preferences e.g. if you always need to communicate through wifi. WebClient allows full HTTP header access and returns in the originating thread and not the UI thread.

XNA inside Silverlight App. Integration at the page level, XNA takes over the rendering. Integration at element level, Silverlight elements in XNA pipeline via UIElementRenderer. Input is shared. So now you can do XNA-3D in your Silverlight app or do your XNA game UIs with Silverlight.

Local database! SQL Compact Edition. LINQ to SQL to query, filter, sort. Object model for CRUD. Application level access, so it's sandboxed from other applications. Background agents can access the database. And there's a DatabaseSchemaUpdater APIs for upgrades since there is no direct SQL access.

Application Model

Fast Application Resume. Apps are not thrown out of memory immediately, at most five apps are held in memory and only "tombstoned" if memory is low etc. So now switching apps is faster. And old apps will continue working, no problem.

Multi-tasking is available, but Microsoft wants to make sure the power usage is minimal and user experience is good. This is why there is no "real" multi-tasking.

The options are: bg transfer service, bg audio, bg agents (periodic and on idle), alarms and reminders.

Using BG audio you have to start playing the sound from a foreground application. A bg app cannot start play but can continue playing. Application will be shut down, but a separate agent will continue running and provide the sound and handle next/prev etc.

BG audio app types: URL PlayList and Stream Source. Former just tells which URLs to play, the latter will provide audio buffers and can have custom decryption/decompression.

BG agents are periodic or on idle. They are initialized in foreground but run on background. They persist across reboots! User controls through control panel and there can be at maximum 18 running periodic agents. Agent runs for up to 14 days but it can be renewed. This is just because if you don't run the application in two weeks, you probably won't even be using it. You can set a smaller run time limit if you want to. The timer is reset every time the app is run.

Periodic agent runs around every 30 minutes and they get around 15 seconds of time. It must have less than 6MB of memory and less than 10% CPU (limits subject to change before RTM).

On Idle agents run when on external power and non-cell network. They can run for 10 minutes and can use more CPU but less than 6MB of memory.

BG agent functionality allowed: tiles, toast, location, network, R/W isolated storage, sockets, most framework APIs.

BG agent functionality disallowed: display UI, XNA, microphone, camera, sensors, play audio (only BG audio APIs).

Agents continue running until the agent itself aborts it, the time limit (default 14 days) is met or the user removes it via the control panel. If you try to add a bg agent and there are already 18 running, there is an exception. The user must remove some agent to allow your app to create one.

One application can have only one idle agent, one bg agent and one bg audio handler. The agents can run whatever tasks they like, but there can only be one of each.

Notifications

Time-based on-phone notifications. Supports alerts and reminders, persist across reboots and adheres to user settings. Alarms are modal, snooze/dismiss, sound customization, no app invocation, no stacking. Reminders have rich information, integrate with other reminders, snooze/dismiss, launches app if clicked.

Background Transfer Service

Start transfer in foreground, complete in background, even if app is closed. Queue persists across reboots and has a limit of 5. Single service for all applications, FIFO. Upload limit around 4MB, downloading more than 20MB only when using wifi. The files are transferred to isolated storage. The 5 file limit is per application, so other apps can download even if your app has its queue full. The FIFO system is global.

Tiles

Local tile APIs have full control of ALL properties. You can update the tile information from your app or background agent and don't have to use push notifications etc.

You can also create multiple tiles per application. The tiles can deep link, which means you can add parameters to the tiles so that they start the application in some other place than the front page.

Push Notification

No API changes, but lots of enhancemens on the reliability, efficiency and performance. Better radio usage, faster state machine, smarter queuing etc. Nothing for the developer itself.

The user can have 30 applications using push notifications at one time now, previously the limit was 15.

Extras

This is one of the great things. You can integrate Bing Search results with your app. There are four item types: movies, places, events and products. The search will show a card for the item and any application can register itself as being able to handle this information. You can e.g. tell the system that you can handle movies and the user can start your application to e.g. buy the movie online directly from the search results.

You can read contacts and calendar entries, but you can't write data. You can start a launcher that saves data, but that requires user interaction.

What Now?

7.0 apps will run nicely with Mango. But if you really want to get the nice features, target Mango already and be ready. Especially the fast task switching is nice for any application.

Today I'm attending Microsoft's Windows Phone Developer Day in Helsinki. Should be interesting, I haven't done much WP development. And it's nice to see something about the Mango. Naturally the Mango part is the last so that people won't just come to see that and leave. But who would do that anyway...

650 people were allowed to attend and they're saying it's going to be packed. There are already lots of people here, more still pouring in...

Keynote speaker is Brandon Watson, the rest of the day is hosted by Jaime Rodriquez. Sessions include Designing for Windows Phone, Introduction to Silverlight and Tools, Application Development for Windows Phone, Integrating with Windows Phone Hardware and the Services, What's new in Mango.

Brandon's Keynote

I'll write stuff about Brandon's keynote here, other sessions are probably handled in other posts if there's interesting stuff to talk about.

He says that this is the first WP Dev conf after the announcement of Mango. So they really seem to care about Finland ;)

In 7 months Microsoft has gotten 1.6 million tools downloads, 18k apps in WP7 Marketplace, 42k registered developers... Not bad, really.

Oh, and people can really stop complaining: multitasking, raw camera access, socket access etc are in Mango. So don't worry. Also Brandon said that apps can continue to work in the background. So maybe the multitasking will be more than just saving the app state, as it mostly is in iPhone.

Bing and Things

Nice! If you search for example a movie, you'll get a product card with information about the movie. You can find information, schedules etc. But the most interesting thing is App Connect. There is a pane where you have direct links to applications that have informed the phone that they can handle e.g. movie cards. The user has a direct link to the application. Not seen anywhere else, guys.

Oh, what about if your app can handle it but is not installed? No worries, it is still shown in the list! So people can install your app directly from search if it looks like an interesting app for e.g. movies. This is cool!

Distribution

There is also a beta distribution option, 100 users, app has to be free, no update etc. Private distribution serves also paid apps, but the app is not publicly visible in the marketplace. And then there's the public marketplace. This is also a very good enhancement.

App Hub

New dashboard, W-8 forms, clear notifications etc. If your app is rejected, you get a clear PDF report stating what the problems were. This is one thing that could be a lot better than Apple's. I've gotten stupid short messages from them and twice they've even said "the app just doesn't work" while it clearly works and on a resubmit they suddenly fot it to work. This should not happen, ever!

Web and IE9

There is background audio available. And it's also available with web browser! You can have an HTML5 app that plays music, you can put it into background, lock the phone, the phone play/pause keys work with it etc etc. Nice!

CSS transformations shown, 23 FPS. GPU is used in browser too.

Boston.com loading. Flash logo shown, but they naturally support HTML5 and videos can be watched without Flash bloat. The web browser seems fast and very smooth, even with a big page like this.

Naturally the browser supports geolocation.

Oh, all this was shown on an actual device via camera, no emulators or other stuff.

XNA + Silverlight

Previously with XNA you couldn't make UIs easily. You couldn't use Silverlight on XNA or XNA on Silverlight. Now you can. You can overlay Silverlight on XNA and make UIs that control the XNA game. This will make localization so much easier since you don't have to have lots of resources for different languages.

Also, you can have controls on top of camera feed with raw camera access.

Sensors

You have raw access to compass and gyro. There is a lot of math done for us so you don't have to care about true north/magnetic north etc. It's done for you. I'm not sure if it's a problem with other platforms, haven't used the compasses.

Sockets, Database etc

No surprise here. Most requested features: sockets and local database access. They're here. As requested. You're welcome.

You have access to contacts and calendar, you have directions selector... With single lines of code.

Multitasking

Fast app resume is there, as with iPhone etc. But what about real multitasking? There are background tasks that allow the app to use some time to do their stuff. At the moment it's about 15 seconds that the app is allowed at a time. It's also inferred that the apps can continue running in the background even after reboot. This would be very nice indeed!

Live tiles updating, battery friendly scheduler, background alerts. You can have multiple tiles for one app that go into different parts of the application.

I hope the live tiles are really battery friendly (Brandon says they really are), at least with Symbian they seem to be really power hungry.

Live Agents

You can pin a part of the application into the home screen. A demo is shown that shows a store selling hardware. You pin an Xbox product info to the main screen, it'll show you e.g. how far you're from the nearest retailer. Click on it and you'll get to the product info in the app. Not the main screen.

Dev Tools

Beta tools available now. Are beta quality, but you can build real apps with them. You can target Windows Phone 7.0 or 7.1 (numbers might change, the latter anyway being Mango).

Demo about a simple app that shows an image that has a PlaneProjection. Reference to sensors API. Create an Accelerometer. Add a delegate. Start the accelerometer. In the delegate change the plane projection with the values gotten from the accel. And the image rotates with the phone. Simple.

Oh, and in the devtools you can now simulate sensor data, especially the accelerometer. You can create XML data for the motions and load them etc. Easy testing with this, for sure!

Naturally you can also simulate GPS data. When will Apple bother to make this possible? With (at least) Qt it's possible on Symbian too.

Q&A

There is no ambiguity here: every single handset that has WP7 will have Mango available to it. Free of charge.

No Silverlight support in the browser itself at the moment.

Any new stuff in the enterprise management etc? There are some announcements from TechEd, but the enterprise stuff probably isn't as great as it should be, but things are getting better.

Full forward compatibility from 7.0 to Mango. No breaking things.

What about NFC? It's not available now. It's requested, but nothing for Mango. Maybe later.

When will the integration with Ovi Maps/Store etc coming? When the first Nokia phone comes out.

Can you sell apps outside the marketplace? No. Certified app marketplace is important. They are figuring out how to allow for homebrew stuff, but there are security problems. I understand this, but I do want some kind of homebrew stuff to be possible.

When will devs get Mango devices? If you are a developer with a device from Microsoft, it'll come some time in the future. If you buy a WP7 device now, there is no clear release date right now.

Who will have the first Mango devicea available? Anyone who happens to be the first.

Custom shaders in XNA? Much requested, a challenge with the programming model. Looking hard to enable it, but not available right now.

Ruggedized devices running WP7? No information about those, handset maker stuff.

What are the restrictions for developers? There are guidelines, you can download them from the marketplace site.

Operator billing is supported and with Nokia it's even better. People are five times more likely to buy when they have operator billing.

No native code support. None. Sorry. C# is to be used. "That's sad" Brandon: "It's not sad, it's horrible!" So yes, Microsoft would also like to have it, but it'll take time and they do have deadlines.

Oh, just wanted to let you know something: I kinda like Qt Quick / QML. It's quite nifty for UIs (naturally since it's copying WPF's XAML ;). It didn't take that long to get into the basic notation, get lists running, some animations etc. Pretty good.

I still have a problem with Qt Creator (in addition to the one I already wrote about). I'm not used to it. It doesn't function like I'm used to. See what I did there? I'm not blaming the IDE, it doesn't have to be exactly like Visual Studio. But it would help ;)

What I don't like is that there are no tabs in the editor. There is a listbox that shows the opened files. There's also a subwindow that shows them. Not the way I like it.

Also I don't like the find functionality. Ctrl-F shows it, it finds stuff, but when I press Esc, it still stays on the screen. And the found words are highlighted. I don't want that. I have to close it every time I use it :(

Also: a kingdom for automatic generation of property methods (AGGGGH!) and why can't I use QList with ListView? All I get is errors about not finding the properties if I don't use QList. And I want to use real types!

I would be happiest with Visual Studio. I had the add-in version 1.1.7. It shows up in VS 2008 and 2010 that I have installed. It kinda works in 2008 but not in 2010. It loads the .pro file and makes a project out of it in 2008, but in 2010 it can't. The project file version is off. Grh. Also in 2008 QML is nowhere to be found. And it doesn't seem to support anything else than desktop. Grhfmggh.

Oh, 1.1.8 is available. Let's install that. Or rather, uninstall the previous one, then install this one. They're still using the crappy Nullsoft installer and not MSI packages. Oh you poor devil children :P

Ok, 1.1.8 won't work either. Why does it say it supports 2010 if it clearly doesn't? Or does it allow creating new projects, just not converting .pros? Gah. 2008 time again...

In 2008 it just gave an error. The system cannot find the file specified. Care to elaborate on which file? No. I don't want to. Naturally. To the command line...

Visual Studio 2010 command line. Ran the command (which the add-in in 2008 kindly did show me), got warnings about Unknown version (160) of MSVC detected for .vcproj. Unknown? You said this add-in was for 2010?

Visual Studio 2008 command line. No errors, warnings about deprecated unescaped backslashes (it's always nice when Nokia ships things that generate warnings). But I got the .vcproj file. Still no QML files in the project, so clearly it doesn't support it. Build and all I get is ERROR PRJ0019: A tool returned an error code from "RCC Project.qrc". Care to elaborate on what error code and which tool? No. I don't want to.

What this means is that by "upgrading" to VS add-in 1.1.8 I lost the ability to even import .pro files. It worked in 1.1.7 a few minutes ago. Not anymore. Oh yeah, I've got the source, I could fix it. But it's not my place to fix it.

So, it's back to Qt Creator. Clearly the Visual Studio add-in is there just to allow people to do something, but not to allow people to actually develop stuff with it. At least if you want to use QML or target mobile devices. That's nice, Nokia. Very nice. Goes so well together with your decision previously to can Carbide.vs, which was the only usable IDE for Symbian development in my book. Carbide.c++ never got to the stage where it was really usable, mainly because of Eclipse.

Disclaimer: yes, I do know that Trolltech did the VS add-ins and it's not Nokia's fault entirely. But hey, they could've at least told the Qt developers that it would be nice if people could actually use QML in Visual Studio (without manual work) and target mobile devices. Even if it means manually making SIS files etc, but just let me test stuff in the simulator...

Better to write a separate story about this problem I ran into. It's a big one, really. It might not affect that many people, but it did me. And it's a possibility for a disaster.

As many people know, the Symbian SDK is still in the dark ages. It can't handle spaces in path names. Stupid. And since I'm not an idiot, I don't want to have all my projects in some C:\mystuff. I want to have them where they belong and that is under my profile directory. Which, of course, has spaces in the path.

Tried to compile a Qt app. Didn't work, the spaces. Ok. Copied the project to c:\nokiaisstupid\project\ (not really, but I'm pissed off right now). Compiled, it works. Nice.

Opened a QML file from the Qt Creator. Edited it. Ran in the simulator. Nothing changed. What the heck? Changed something else. Nothing. Strange.

Changed the original file. Changes were visible. Umm, what? Qt Creator opens files from the new location, but builds them from the old! That's nice. And no, clean all doesn't fix it.

Let's remove the original file altogether. Ran just fine. Edited the new file. Still uses the old file. Which doesn't even exist anymore! So it caches stuff somewhere like an idiot?

Clean all. Rebuild all. Still using the old version. Which still doesn't exist.

Search all files in the project directory for the old path. Not found. Search all files in the project directory for main.qml. All point to the new path.

Close the simulator. Close Qt Creator. Still the old version!

So, where the hell is this old version cached? Why does Qt Creator still use it, even though the path is not in the project files, the file doesn't exist etc?

Oh well, let's build a deployment SIS for the device. Maybe it'll notice that something's missing then. Nope! 329 warnings from the Qt SDK itself, none from my code. No errors. SIS created.

Install SIS on device. Oh, right. I can't install the smart installer version, since it doesn't seem to work on E7. Let's send the stupid installer version then. Wow! It uses the new version. As it should.

So, I'm stuck in a situation where Qt Creator doesn't realize that it should use the new file. It keeps its old version somewhere deep inside the simulator and doesn't give up on it.

How about it, Nokia? A quick fix for this in order? Or should I just never create projects in one place and then move them? And recreate the whole project that's currently not working?

The root cause for all this is the stupidity that is simulator work: there is a separate build folder for simulator stuff. Which has a separate makefile. And the build directory is per user. And the path stayed the same. And the makefile has a relative path (as it should). So it just kept on copying the wrong files.

So the fix as I see it: don't use any stupid separate folder for the simulator! Everything I do on a project X should be either inside the project X's folder or somewhere in simulator's/Qt Creator's folder structure. No folders should be created anywhere else. It's just stupid. Oh, right. You can't do that. Since Qmake does not support build directories below the source directory. Cool. But it still builds this one quite nicely without problems when I put it under the source folder. Maybe I'm just lucky.

Or at least use relative paths or give an error message. Yes, there is a warning, but it doesn't say why or what things will be caused by not fixing paths by hand.

So there. I'm sure this will go under "a minor thing that nobody notices since they'll never move files around."

Recap: when Qt Creator creates makefiles for building, please use absolute paths. Also, please use a folder under ProgramData or some other reasonable place. Don't clutter my project folder with Project-build-desktop, Project-build-Symbian, Project-build-maemo etc. They're not my projects. They're just build results. Which are NOT laid out like this in any other IDE that I know of.

Please? Pretty please?

Now it's naturally time to try to get my Qt Quick application into the E7 for testing. Updated Qt to 4.7.2 (it's nice that it's only some gigabytes when updating...). Qt Creator up and added device configuration. Build, get a warning about spaces in paths and build bar goes red. Nothing happens. For some time. Change view to Compile Output and there's the typical error about missing path, path being cut at space. Great.

So there are two problems here, still: Symbian toolchains don't handle spaces in paths and Qt Creator can't even show errors in the Build Issues view when building for Symbian.

Hey, it's 2011. When will you guys understand that? It's NOT ok to install your stuff into the root folder. Not even if you can't make stuff work with spaces. Because the correct thing to do is fix it so that it does.

So now I have to save my Qt projects somewhere else than all other projects I do, just because Nokia can't get SDKs done right? That's sooo cool.

Oh well. Let's see if I can at least get the device connected to Qt Creator and get stuff in it. USB connected, drivers installing... And no, I will NOT install Ovi Suite to this machine!

CODA installed on device. Reboot. USB cable in, device says that debug services are available. Qt Creator won't show the device in project settings. I didn't expect anything else...

Setting Up Development Environment for Symbian has been read and done. But noo, naturally it won't work. So what's next? Maybe it won't work with CODA, you have to have App Trk? Though the documentation doesn't say so. Let's try that...

Nope. Not available in Qt Creator still...

Well, let's just make a SIS out of it and send it to the device without Qt Creator. But, how? Build, done. No SIS file. Deploy? No, that would require a connection to the device. Which I don't have. So...? I'm a total newbie with Qt Creator and it clearly isn't as simple as it could be. It seems that I have to create a new build step that runs make sis. Manual work is always great.

But that requires manual installation of Qt on the device. Not nice. So I have to use make installer_sis. Now I get a package that doesn't complain. Testing on device...

Installing... This'n'that... Error: device not supported. Oh really? Why not? E7 isn't supported? That's not going to help. Let's try installing the sis package from the SDK manually. As I said, I do like manual work when developing. It'd be much better for the end users, too, if they had to install Qt manually, don't you say?

Installing... Installation complete! So, yes, E7 is supported. Just not by the smart installer. Ok, this whole thing is beta (even by name, I think it will be beta quality for a long time still), maybe they'll fix it soon.

Try installing the smart version again. No go, not supported. Install without the "smart installer" and it went through. Not so smart after all.

But woohoo, it runs! So, all I have to do now is send the SIS file manually every time I build, since the connection from Qt Creator to the device won't work. And I can't use the "smart installer" since it won't work with an actual device.

So, anyone more familiar with Qt Creator and development who can tell me what I'm doing wrong? It must be me doing things wrong, it can't really be that these things don't work, can it?

Also as a side rant: why the heck hasn't Nokia implemented a better support for Symbian in Qt Creator? "Oh, you can use the testing UIDs when developing and when you want to send the app to Symbian Signed, you must remember to change the UID by hand to another value." Umm, hello? Isn't this supposed to be done by the IDE, not by the developer? Ah, sorry, forgot: manual work is fun. And not error prone.

And it's nice that compiling Qt application for Symbian causes hundreds of warnings. No, not a single one from my code. They're all from the Qt code! Developer 101 time: warnings are bad. You shouldn't get any when compiling. Even if they're "only" warnings. Clearly Nokia doesn't know this.

What the heck?!? When I copied the project to another location (because the Symbian SDK can't handle spaces), cleaned everything many times, but STILL the Qt Creator loads QML files from the wrong place! That is, when I double-click a file to open it in editor, it loads it from newpath\test.qml. When I build the app (for the simulator, at least), it loads it from oldpath\test.qml. Which obviously doesn't work. Separate path handling for project viewing and building? Hello? Idiots anyone? Sheesh!

I got a comment about endorsing a platform that controls the software that is installed on the device, especially since I've complained a lot about Symbian Signed. I thought I might explain my reasons for this a bit.

History of Symbian

Before Symbian Signed things were nice on the Symbian front. You could make apps using all APIs and distribute them the way you liked. No restrictions. Fine. But then came the horrid Symbian Signed and Capabilities. Good idea, implementation sucked.

Capabilities

The main problems with capabilities were that you could only get certain ones without paying and if you didn't pay, the user got a reminder claiming that the application might steal your personal information and whatnot. So scary tactics to force people into Symbian Signed.

Also, the capabilities had to be given up front which was idiotic. And there was no possibility to select which capabilities you allowed the application to have. Yes, I allow the app to read my contacts. No, I don't want it to get my location. Umm, ok, I can't install the whole app? Nice...

Also the capabilities were too coarse. For example, my mIRGGI needs network access, which is fine for most people. But when installing S60 shows that mIRGGI can also make calls. Most people probably don't want that to happen (and it won't, mIRGGI has NO functions that could make calls). But they can't tell that to the OS. Stupid.

Symbian Signed

The first version of Symbian Signed was horrible. First you had to get a developer id which means spending $200/year for a code signing certificate from a single provider. This was easy, but cost quite a bit, especially for freeware developers.

Then if you wanted to get your apps to the public, you had to pay for "testing." And I put it into quotes because it wasn't really always testing rather than nitpicking. There were cases where the application showed a version number incorrectly (1.2.3 instead of required 1.02.3 or something) and the testing failed! And when you fixed that you had to pay for retesting.

Also the payment was for each and every version. Make an app, sell it to 100 people. Make an update, pay again but you might not get any more purchases. Make another update and so on. So you're paying and getting nothing in return. Why would companies want to fix or update their product often when all it meant was money lost? (I know this isn't always so harsh, but still)

Discount Testing

Then Symbian Signed was transformed so that you could test the stuff yourself. All you had to do was pay $20 per shot for a quick signing. $20 for signing? That's a lot. Once again, every little fix or update you made cost you that much. Better, but still not reasonable.

There was also for a limited time a freeware testing thingy where you could get some freeware apps signed for free. But they didn't like it if you released too many versions too soon etc. And later on it died off.

The last try was to make the whole Symbian Signed free for Symbian/Qt/Java apps. That's when the system started to look like a reasonable thing to do.

The whole time the explanation for this was to make sure that the origin of the application could be determined. And the whole time there were certificates available for Java, Windows applications etc which did the same. The difference? You could sign your code yourself. Without paying for "testing."

Apple Developer Program

Apple started the whole thing with a commercial developer program. You pay $99/year and you get the tools, testing (and they even do test, even though I've got some "it doesn't work", "surely it does, I've tested it a lot", "oh, sorry, yes it does" problems once) and distribution for that price. Fixed price. And that's the key difference here.

You can also distribute ad hoc applications, which means that you input the device IDs for a maximum of 100 devices and sign the application for those with a certificate that you get from Apple. Usually done for testing purposes.

Larger companies can also get a system that allows them to distribute apps for their employees freely, but that requires a 500 employee enterprise IIRC.

And what about capabilities? For example, when running a program that wants to get your location, you're asked if it's ok. When running, not when installing. And you can allow/disallow this whenever you want to. The same with notifications etc. This is the right way to go!

Windows Phone Developer Program

To develop for Windows Phone 7 you can get the tools for free. But if you want to distribute, you'll pay $99/year. And no hidden/extra costs here either.

Microsoft also has stated (after the jailbreak thingy) that they're looking into allowing the installation of applications on the devices without paying or going through the marketplace. And I also hope that they really make it possible. And I hope they won't make stupid restrictions for the applications.

I have no knowledge about how capabilities are done in WP7, I've only seen them declared in the application XML file. Must see into this.

Conclusions

WP7 development is more restrictive than Symbian/Maemo/Meego, that's for sure. At least for now. But Symbian's capabilities and track record with the whole Signed crap is not at all good. And I personally rather pay $99/year for development environment that actually works than kill my sanity with a free one that doesn't. I did pay Apple's fees for a couple of years before I made a cent on anything iOS. Just because I wanted to learn it and the environment was only half-crap (XCode, Interface Builder etc are horrible but not nearly as bad as Carbide.c++ etc). And I'll surely pay for Microsoft/Nokia the yearly fee to make apps for WP7 even if they're freeware. I can afford it and I know what I'm getting in return.

Now just waiting for Microsoft's move on the 3rd party app installation front. I don't thing it'll happen on the next update (which is due out very soon), but maybe later? And since Nokia won't get any devices out for a while, it can wait a bit.

But I don't want to wait, maybe Microsoft could update the Silverlight they already have for Symbian. Then we could create apps for Symbian and WP7 with it. That would be cool. Qt for Symbian/Maemo/Meego and Silverlight for Symbian/WP7. And surely Moonlight could be used for Maemo/Meego too, so we could get a truely universal platform? ;)

Ah, it finally happened. I didn't think it would, but I was wrong. Nokia is taking on Windows Phone 7. Great! Finally they'll have a working platform with great development tools!

There are millions of people that are probably yelling NOOOO! at the moment. Shut up, I tell them. If you have some anti-Microsoft thing, it's your problem. If you'd just take your head out of your nether regions, you'd understand that Nokia has been so bad for developers, their UIs have been crap and they can't even make a decent browser in several years. Not even if they have WebKit and others available.

I would've thought that Nokia would've possibly made a new UI for the phones (not a good thing, taking account their track record), or at least gotten Qt to work in it. But no, they're keeping Qt for Symbian, Meego etc.

What about Symbian? They say they won't throw it out, yet. But they aren't telling us what it will be used for. And Meego? They'll release "a device", but what? I think Meego probably will work for tablets etc, but there's no point in making another UI for phones. Since that's what it would be.

I'm very interested to see what happens next. When will the first phone come out, what will Nokia's hardware knowledge bring to the table.

And for those that are saying "Microsoft is taking over Nokia." The whole point for taking on Elop was to get Nokia to go to another direction. It's been going downhill for so long. Why can't you just accept the fact that maybe, just maybe, a partnership (not a takeover) with Microsoft is exactly what they need?

Also, how many of the people whining about Windows Phone 7 have actually used it? Developed for it? I personally have not held a device in my hand. But I have developed some test applications for it. And I can say that in the time that it took me to make a mockup version of Telkussa Mobile for Windows Phone 7 was 15 minutes. No previous knowledge about WP7 development (and not much about WPF development either). It's just so simple to do things and the development tools actually work!

I've done the application for Android too, to some extent. Most of the time went to fighting with Eclipse and ADT (they're quite unstable, also some x86/x64 stuff etc). I did get it done, but it's slooooooow. Horribly so. Since there is lots of data handling when loading TV guide data in the beginning.

I'd like to do it for Symbian, Qt, Qt Quick too. But I'd kinda in need of a minor braindamage (major in case of Symbian). The development tools are alien to me and don't seem as mature as I'd like them to be. In case of Symbian, Carbide.c++ is crap. Even after years of development. Qt Creator is probably less crap, but it's complicated. It took me a while to even find out how to change the target of compilation. Could be just my inability, but still. And also, the applications that are produced by Qt look different on the devices. Not nice to use that kind of a platform.

The only platform that actually has that application out in the wild is iOS. It took me quite a while to get it done, since XCode is horrible and iOS APIs were alien to me. They're not horrible, but it takes a while to get into a platform, know how to use iOS's memory handling (quite awful), threads etc etc. But it's much less horrible than Symbian. Android, I'm not sure. I don't have enough experience about it. But the XML crap UIs don't tickle my fancy, at all. WPF/Silverlight did it right since you don't need any getControlById() and casting etc that you need with Android.

So, I'm intrigued. Very much so. If Nokia needs a developer for WP7 stuff, I'm interested. You didn't get me to work for you previously, but now you can call me ;)

So, once again I wanted to try out Qt for Symbian, just a bit. I've installed Nokia Qt SDK previously but not used it. I've once tried Qt Creator and found out that for me it looks like a quite horrible thing. But now I wanted to try it again. So, please correct me if/when I'm wrong about something.

So, let's start by creating a project for a mobile application. Very straightforward thing. Naturally I wanted to use the UI designer, since it's supposed to be so great. Not so straightforward.

I put a list widget on the main window. Looks like a normal Windows list. Run on simulator. Looks like the horrible basic Symbian list. Umm... So, the UI designer is useless, since the Qt applications won't look the same on different platforms? Great. Just great. So it's all to be done in code, just like before. Why am I thinking about Java all of a sudden. "It's portable, one app will run everywhere" and all that jazz. And the reality? Different apps, different UIs for different platforms etc are/were required. And that seems to be the case for Qt also.

What I would've wanted was a separate thing for developing different platforms, if indeed Nokia didn't want to make Qt look and act the same on Symbian as it does on desktop platforms. Why clutter the property view with dozens of settings that do nothing on Symbian? Why show the list control very differently?

I run the application in debug mode. Complains about cdb not being installed (hey, it's Windows. Why would I use some mingw crap when I can use real tools?). Ok, I turn it on and it finds the path. Still complaining. Until I restart the whole Qt Creator. Nice.

Oh, every time I run the application, the UI designer turns into some XML view, which can not be edited, and I have to switch it to GUI mode every time. Why? What's the point? Why do I want to watch read-only XML when I run the app? Hello?

The simulator/created application shows Options and Exit menu buttons. Even the Exit button won't work. The red phone key doesn't exit the app. Why oh why?

Updating the Qt stuff is also nice. Lots of updates, crash when it has downloaded 2 GB of stuff. Naturally we'll start all over again. Great. Wonderful design. And why the heck are there always mingw and MSVC2008 versions of stuff? And why the heck is mingw simulator twice the size of MSVC2008? Come on, Qt people, MSVC compiler/debugger etc are available for free. Just ditch the whole minwg already, or at least make it an option, not a default...

So if I understand things correctly after this test: I can use Qt Creator for coding, but not the UI since it won't look the same in different devices. And I can't create separate UI designs for separate devices easily. So it's all code, code, code.

I'm thinking about testing custom drawn list items. They should work. But I'm tempted to bet that they won't get drawn correctly in the UI designer, only when running. But we'll see.

So not a great start, but not a horrible one either. What I (emphasis on the word I, others may have other needs) would want is to do everything in Visual Studio (2010, thank you, 2008 is already old). I would like to have an UI designer that actually shows how the application will be in the actual device. I would like to have a possibility to design different kinds of UIs if I want to. I know that QML is coming, but...

More when I have time to write it. Too busy doing other work on platforms that behave better (yeah, Interface Builder from Apple is horrible crap, but even that seems to be better than this).

Binaries for PostGIS x64

Since I'm an eager PostgreSQL and PostGIS user and I'm sure I'm not the only one interested in using these in 64bit now that it's possible on Windows, I thought I'd put the PostGIS binaries up for grabs if someone needs them. PostGIS developers will have files available for Win32 PostgreSQL 9.0 soon (now?), but they won't distribute 64bit. So here you have them. I hope all the needed files are included, do tell me if they aren't.

Copy the postgis-1.5.dll to PostgreSQL's lib folder and the other files to bin folder. Then just run the installation scripts from PostGIS distribution (not included) and you're all set.

Note! I have not run any thorough regression tests on these. They are compiled from the SVN sources (r6009 r6029) and I've only modified a couple of places to get them to compile (read more below). I have run my own applications on them, so at least there aren't any immediate showstoppers with them. But as I said, no guarantees! I hope I'll have time to run tests on them someday.

Compilation and Whining

I really can't understand why PostGIS developers still want to compile the whole stuff using msys/mingw and that kind of stuff. We have Visual C++ (yes, the compiler is available for free), everything compiles with it and you don't have to whine about how hard it is to compile stuff for Windows because it's not GNU. Just to give some hints: I have never compiled GEOS, PROJ, PostGIS etc for any platform. Still I had Visual Studio solutions done for the whole stuff in under 30 minutes. It's not hard, really! It's only hard if you insist in doing stuff your way and not the way it's supposed to be done.

So, the binaries are compiled with the newest Visual C++ compiler and optimized with the default release settings. I had to change an initialization of two arrays (there is a notice in the source that it's not nice to do it as they've done) and change some includes to get things rolling.

Binaries for PostGIS 1.5.2SVN for PostgreSQL 9.0 Windows x64

28th Sep: updated to r6029

And thank you for the PostGIS authors for clarifying my whinings :) And especially for creating and maintaining the whole PostGIS, which I love!

So, finally. Nokia is providing free application signing for all. They finally understood that they really won't get as much applications to their Ovi Store if they keep this stupid moneymaking business alive. We'll see what happens next. There's still the stupidness of Symbian development and the lack of stable or in-device Qt libraries. So, maybe in a year or two...

Apple naturally wants developers to try their new betas of the iOS and SDKs. That's fine. One thing that is not clear to all is that once you start testing those, your normal workflow is disrupted completely. Could be that this is old news to many, but wasn't for me. I've been doing my real work with decent tools so I didn't even think that things could be this bad. But I should've known. It is Apple we're talking about.

I installed iOS 4.1 beta2 on my phone. Naturally after that you can't use the phone for development unless you install the beta2 SDK too. So let's install it. Since it's an Apple product, it naturally won't support the previous versions. You can select the minimum required OS version for the app, but that doesn't help much.

You can't use the machine you installed the beta SDK for sending applications to the App Store. XCode uses the installed beta SDK for compiling and Apple won't allow that. No matter if you use any beta features or not. Great. So you need to have a whole new system to use with the supported SDKs to compile the apps.

Now, I want to make an application that works with iPhone OS 3.1. I can do that with the iOS 4.0 SDK. But what is impossible is to get a realiable feeling about the things that will work and what won't. Since the application is compiled with the 4.0 SDK, you can use any 4.0 features and YOU have to make sure that you don't use anything that isn't in 3.1.

Naturally Apple has mentioned that you should test if the classes are available. That's simple, right? Wrong. Since it's Objective-C, all binding is done runtime. You can use any classes that are available, any selectors that are available. Even if they are not available during compilation. This is one thing I don't like. I like hard bindings. But is it just a question of preferences? Nope, as one developer noticed (I don't have the link here right now, I'll add it later).

iOS 4.0 has new classes, that are only usable in iOS 4.0. That's what they tell you but it's not the reality. There are classes that exist on earlier SDKs, but they're just not public. So, if you do the suggested thing of testing if [SomeClass class] is not nil and use the features then, you're getting into trouble. You might not get nil for the class, since it exists and you have access to it, but it might not be the same class. So you can't call the methods you think you can.

So, if you want to support previous versions (naturally Apple doesn't want this, they want you to upgrade immediately to a new versio), you have to some nasty voodoo. And the tools don't help at all.

There is a new XCode coming up though, which has some things fixed that I personally don't like in the current one. But it's still far from a tool that I'd like to use. And at the moment it doesn't look like any of this SDK mess is going to be fixed. And why should it, since you can always just use the newest SDK. Who cares about the previous ones. It's not like the iPad still only has OS 3.2.

I've been trying to create test user accounts for the In-App Store stuff. I've never been successful in that. I've sent three support requests for Apple and never gotten any response. I really don't understand why is it so hard to tell me what I'm doing wrong, since clearly it can't be that Apple's whole test user creation thingy would be broken. That would get lots of developers angry. But no, they don't care, even though they'd get more money if I could get the purchasing working.

Second thing is that they rejected my application a couple of times. They said it didn't work. I told them I've tested it with a couple of devices and with the emulator. All work. Surprise surprise! The problem was at their end and suddenly they accepted the application with no changes!

Third problem, and this is a major one, is that they can't get their emails through to me. You know, I submit an app, they reject it, I never get any information about why. When I email them about this, all they can say is "we'll resend the email." They've tried that several times but the emails don't come through.

Now, I could suspect something wrong with my email severs, but here's the thing: they claim to send to two email addresses. They are on different servers. They are on different email server software. And neither show any emails even trying to come from Apple. But still their support emails come through. Strange. Oh, and I've asked them to copy the error information into the support emails, since they come through. Nope, they don't seem to be able to do that.

I've also tried to suggest to them that they could add a section to iTunes Connect where you could check the error information via the web. That way if the emails don't arrive, you can always check it there. But no. That would be too helpful. They can't do that.

And the most idiotic thing at the moment, and the reason I'm writing this: you can't test applications on devices with newer firmware than the SDK supports! Meaning that every time Apple updates iPhone OS, even a minor update, all developers MUST download the 3+GB SDK package, once again. No matter what you're targeting. You can't use the device unless you update.

I have 3.1.2 on my device. My XCode supports up to 3.1.1. My project is set to produce 3.0 binaries. You'd think I could test the application on my device, since 3.1.2 supports 3.0 binaries. But no, that won't do, since XCode doesn't support the firmware. Two choices: downgrade or install a new SDK. So I'm waiting for the download to finish. Nice. And naturally they can't just put up a diff/upgrade package. All 3+GB every time. Great job, Apple.

But then again, this is the case with Apple's updates too. Huge packages that replace the whole thing. A 160MB update just to fix a couple of security flaws in OS X? Is there something they're not telling us or are they just idiots and can't update the actual files that were changed? Also updating Java in Tiger was fun. Update, reboot. Another update, reboot. Another update, reboot. Why the hell couldn't I just install the latest update and be done with it?

I know, I've been quiet, the certificate is old and the source isn't available. I do apologize. I currently don't even have a machine that would have a working system for compiling mIRGGI, since Carbide sucks, the SDKs suck and Nokia doesn't care about compatibility. You know, the Symbian SDK emulators crash on most people on Win7. It's not like Nokia'd have had time to test them and fix the problems (since they knew they crash on Vista and they barely work on XP). And I'm saying Nokia, because they own Symbian. I'm not letting them use any more of this "it's not our fault, it's Symbian's" stuff.

So I'll try to get the certificate thingy fixed by compiling new versions and the source up somewhere so the interested parties can take a look. Beware: no comments. But that's normal, right?

I'm horribly busy with my studies and stressed out. If you want to cheer me up, send me a plain old postcard. That would be so nice. The address is:

Sami Kuhmonen
Suovatie 18A
FI-01660 Vantaa
Finland

But please, no pipe bombs or anything like that. Thanks!

Oh well, you really don't like me enough :( But as promised, I'll give you something. mIRGGI goes shared source. Which means that I'll open the source, you can add to it and send in the patches and whatnot, but it's not GPL or other crap. One big reason is that I don't want 843975984 forks of mIRGGI just because of "I want this dot to be there and not here" folks. And you're not allowed to use parts of mIRGGI in your own projects. Just because I'm evil.

So stay tuned. It'll happen soon. I just have a physics exam tomorrow, for which I haven't studied, and other stuff. But soon. You'll get to wonder the horrors of my coding and make mIRGGI even better.

Good? Bad? Don't care? At least the development shouldn't be just on my shoulders.