Universal app architecture RRS feed

  • General discussion

  • Hello, I would like to discuss how complicated universal apps are and share best practices. I really like One platform trend, but I will be critical is this post, because I believe this should be improved in near future.

    Universal app is presented as a three-projects-solution, which works nicely in demos, but much worse in real apps. There are two major system requirements, which are not compatible with this idea:

    • SQLite is platform specific and cannot be part of Runtime Component (without sqlite-net package modification [I really don't want do that every time package gets updated])
    • The class implementing IBackgroundTask must be located in Runtime Component (I understand it sounds logical in terms of saving system's resources).

    The background task downloads data from server and stores it locally, which means it needs SQLite layer. The simplest architecture of an universal app having SQLite database and Background Task declaration is this:

    This is quite complicated, isn't it? If it is possible to have a SQLite layer in single universal runtime component it would reduce need of 5 separate projects:

    I'm still missing why database API was dropped. Why SQL Server Compact was not just replaced by SQLite under the hood.

    Is there any possibility to reduce 8 projects and still have an universal app with a background task able to access SQLite database?

    Tuesday, May 6, 2014 7:17 PM

All replies