Comments, Code and Qt. Some words about the wonderful world of software engineering

26Apr/143

Why I decided to unpublish Podcatcher

Posted by kypeli

So I've announced to unpublish Podcatcher from the Windows Phone marketplace. Podcatcher has been a dear project to me for many reasons and I've noticed it also had some satisfied users. In this blog post I try to open up some of the reasons for unpublishing it.

Code cruft

Podcatcher was (one of the other) projects that I used to teach myself how to do Windows Phone programming. Or even C# programming for that matter. When you start a new project in a completely new environment and language you tend to make a lot of mistakes. And then you fix them. That's how you learn, right. But some things are more fundamental than others. One of the things that I couldn't fix anymore - a thing that was so fundamental - and a thing that I today for sure would have done differently is how to model the state data using Linq-to-SQL DataContext. It sits at the bottom of every other model that I have. I already once redid the DataContext functionality by properly disposing them inside using() statements. But at this point of time to go forward I would need to redesign how I lay out my data in multiple DataContexts to handle concurrency better and make it easier to update just the correct pieces of data. Some of the bugs that I've now faced were DataContext.ChangeConflictExceptions which are especially nasty to debug and fix. But basically they mean that the data models are not holding up anymore. Another major pain point has been how the UI components are being updated from UI events that are being fired and updating the data models. This is related to the previous point about the need to do major data model changes. Nowadays I would never have used the Events like I did in the beginning. First they felt like the signals and slots from Qt, which I am very familiar with. So I used them like Qt's signals and slots to update the models that were tied to the UI. But in the long run this became somewhat messy and uncontrolled. This, too, would have required some major changes to fundamental functionalities of how the UI is being updated. Today I would have probably used something along the lines of Rx to handle the events in the system.

async and await

Boy, if I would have been able to use async and await from the beginning instead of BackgroundWorker as my threading model, the code would have been so much cleaner and more maintanable. But because Podcatcher originally targeted Windows Phone 7.5, it wasn't available at the time. The application was then moved over to Windows Phone 8.0, but all the critical threading code and model handling had already been implemented. This is also one of the teaching that I got along the way and I am glad I first did it "the wrong way" because now I can appreciate async/await so much more.

Windows Phone 8.1

Microsoft announced Windows Phone 8.1 at the Build conference. It's a great step forwards for Microsoft but also to all Windows Phone users. Windows Phone 8.1 will bring even nicer applications to end users with more fluent animations and good looking UIs. Why does this matter for Podcatcher? Well, Podcatcher has never been really a poster boy for good looking UIs. I am not a designer so the UI is what I call a "developer graphics UI". So for Podcatcher to meet the demands of what a Windows Phone 8.1 app should look like would require big efforts. First of all, it should be a Windows Phone 8.1 XAML application (as opposed to a Windows Phone 8.1 Silverlight application. Confusing, I know) because not all of the animations for Windows Phone 8.1 are available for Silverlight applications. I could probably try to convert the application from a Windows Phone 8.0 application to a Windows Phone 8.1 XAML application, but I have my doubts about this since my upgrade from Windows Phone 7.5 to Windows Phone 8.0 was not successfull. Yes, the Windows Phone 8.0 variant of Podcatcher is an application that I started from scratch in Visual Studio. So first I would need to make the Podcatcher a Windows Phone 8.1 XAML app to be able to utilize the new animations and other fancy stuff available in the new platform. Then I would need to make Podcatcher look even more appealing by probably doing some major UI design updates along the lines of adding new animations. With all the stuff I descirbed above, this is somewhat of a big hurdle.

The Podcast app

Microsoft is adding an app called "Podcast" that comes preinstalled on every Windows Phone 8.1 device that is bought from a retail store. How the heck am I going to compete against Microsoft in this space? This is probably the reason why I don't have the energy to fix the issues that I've described earlier. After all, yes, the issues are "just code" related and you can always write new code, right. But with Microsoft having their own podcast app in the app list preinstalled does not really add any extra motivation to make the necessary changes.

So why?

So why did I unpublish the application in the end, instead of keeping it as it was? I guess it boils down to two things: pride and time. Pride because I am not proud of Podcatcher anymore as it is now and as we enter the Windows Phone 8.1 era. It should be so much better, nicer looking and coded in a different way. I know I can do it now, but not with the problems it carries on its shoulders. Time, because I don't really have the time to do the necessary changes but also because I do get feedback (positive, but also complaints and bug fix requests) that I feel bad about.  I don't have the time to fix the issues or add the feature requests. So in the end it feels like the application is not complete anymore and its just easier to let it go.

What next?

All of Podcatcher's code is open sourced on GitHub with the GPL license (except for the Telerik components that the Windows Phone 8.0 version depends on). Go get the code from here: https://github.com/kypeli/Podcatcher. As for me, I will now code something else 🙂 Yep, I've installed the Windows Phone 8.1 SDK so I will probably do something else for Windows Phone in the future. No idea yet what. Starting from scratch and to be able target the more mature Windows Phone platform feels great. But one thing is certain: I've learned so much from coding Podcatcher that the project has not been in vain. And now that the code is out there, I hope it will help someone else too.

Technorati Tags: , , ,

6Dec/117

A MeeGo developer’s endeavors to the Symbian Qt world

Posted by kypeli

I've been working with Qt for a while already and we all know what a great cross-platform framework it is. When Nokia bought Trolltech in 2008 it was clear that Nokia wanted to make Symbian development easier. However, the QWidget based toolkit would not fly on Symbian, or any other mobile platform for that matter, so Nokia built some mobile UI frameworks on Qt (and oh boy Nokia is good at building frameworks for everything. Everyone should have at least one framework, if not two. I could write another blog post about that...). But while people in Europe were fighting over their frameworks, it was not until the guys and gals in Brisbane came up with QML when everything changed. Qt could finally be cross platform again and in an elegant way! Symbian just isn't my cup of tea. But that doesn't prevent me from wanting to write something for Symbian if for nothing else other than being able to say I've done it. But just thinking of Symbian C++ or Avkon makes me feel sick. This has changed thanks to QML and especially Qt Components. Also Nokia has finally been able to put out a single SDK that I can just install, write Qt with, deploy the same code on any Qt-based Nokia mobile, publish in the Nokia Store and... Profit! Right? Well, my opportunity to find out came now thanks to my podcast application, Podcatcher for N9, that I've written for the Nokia N9 smartphone. It's has a MeeGo Harmattan Qt Components based UI with a Qt C++ middleware. These are my comments as a former MeeGo developer on the journey to the Qt world of Symbian.

Technorati Tags: , , , ,

17Aug/115

Updates regarding Podcatcher for N9

Posted by kypeli

Podcatcher for N9 has been submitted to Nokia Store for approval! QA process is still pending. Let's hope it's soon available for download on your MeeGo Harmattan device! In the meantime, enjoy the latest screenshots from Podcatcher for N9. Many thanks to Nikui for help with the layout and UX! 🙂   There's also a nice video preview of a beta version of Podcatcher on the MeeGo Experts site!
And if you have any feature requests regarding Podcatcher for N9, just add them here as comments or email (you'll find the address on the About page). I definitely have some improvements that I want to add to future versions of Podcatcher - the development will go on!

Technorati Tags: , , , ,

11Aug/1126

Introducing Podcatcher for Nokia N9

Posted by kypeli

Your intelligent podcast client.

Get it now!

Podcatcher for N9 is available from Nokia Store now! There is a free, lite, version that is limited to three subscriptions only. If you like Podcatcher for N9, I hope you will purchase the full version that has unlimited subscriptions. Links to Nokia Store are below. Source code for Podcatcher for N9 is available online too at http://projects.developer.nokia.com/hpodcatcher.

So what is it...?

Podcatcher for Nokia N9 is a new podcast client that I have been working on for the past couple of weeks. Because I am an active podcast listener, I found the lack of a podcast client somewhat of a loss when I received my Nokia N950 developer device. There are great podcast client out there that will definitely hit the Nokia N9 via Nokia Store sooner or later, but I wanted to create a client that would fit my podcast subscription and listening needs and that would run great on the Nokia N9. I took some inspiration from previous podcast clients that I've used on Android handsets and I now want to present the results. Finally, I wanted to make the performance of my podcast client as good as possible. The backend of Podcatcher for Nokia N9 is written in C++. The UI utilizes native widget thanks to Qt Components and Qt Quick, while the data is cached into a local SQLite database. This all ads up to some great performance. Please have a look at the screenshots and the video below. I hope you like them!

Technorati Tags: , , , , , ,