Application development

[unablys]

Hi,
I'm a IT student and I would like to help with developing this app. How can i help?

[FlyingSheepOnSailfish]

Zitat von unablys [email protected]:

Hi,
I'm a IT student and I would like to help with developing this app.
How can i help?

---

Reply to this email directly or view it on GitHub:
#1

Thank you for your interest.

I started AbstractUI in the very early days of the Sailfish Qt4 Alpha.
The idea, based on work by Thp was to facilitate the development of
SailfishOS and Harmattan apps from a common code base, by isolating
out from the app dependencies on platform specific stuff into an
abstraction library.

Or to be even more precise, the idea is to save development time by
maintaining a common application code base, as opposed to having to
support 2 distinct but somewhat related application code bases, one
for the Harmattan version of the app, and a second for the Sailfish
version of the app.

Since then a lot has changed: while I am still convince that there is
a case for such an abstraction library; I am now in 2 minds as whether
the concept is both desirable and viable. I have been meaning for some
time to post an article on this topic to my Sailfish blog, but your
query has promoted me to actually put pen to paper.

In the old days Sailfish was based on Qt 4.8.3, which was technically
close enough to Harmattan's Qt 4.7.4 for most differences to be easily
handled by such a library.

However SailfishOS is now based on Qt 5.x, the differences are now
much greater, especially in the mobile focused parts that used to be
in Mobility. Some of these are dead as door nails, others have moved
to Qt Add on modules with a hight degree of refactoring. (AbstractUI
was originally intended for abstracting UI components, but there is an
equal case for abstracting backend functionality like GPS, Messaging
as well).

There is the problem too of which shared libraries are available on
each platform (and which of these are kosher for entry to the
respective app stores).

But probably the hardest not to crack is the problem of different UI
paradigms. While both Harmattan and Sailfish Silica are swipe based,
there are substantial differences. Harmattan had a toolbar, Silica
does not, pullley menus can be used instead. Harmattan had tabs, these
are completely missing by design from Silica (the suggestion here is
to use menus…). Pages should be used instead of dialogs etc. Those who
preach that the UI should just be a throwaway layer easily recreated
for a new platform ignore the fact that on many mobile apps the UI is
still a major part of the code.

Then there are technical problems too. While QML can be transparently
wrapped, C++ elements can be only partially. Enums can get lost, and
thus equivalents need to be offered by C++ plugins belonging to the
library.

While these increasing differences make an abstraction library seem
even more desirable, they certainly make it much harder to achieve,
with the library having to do ever more heavy-lifting, as opposed to
just simple wrapping of components.

If we take the example of the missing tabs there are a number of
approaches an common-code base app could take. Some of these are:

1. The abstraction library provides Harmattan style tabs for Silica:
   both the Silica and the Harmattan app use tabs. --> Harmattan UI
   paradigm is leading.
2. The abstraction library provides Silica style pulley menu for
   Harmattan: both the Silica and the Harmattan app use pulley menus. -->
   Silica UI paradigm is leading.
3. The abstraction library provides a component with a name something
   like "SelectionWidget". On Silica this wraps a pulley menu, on
   Harmattan a tab set
4. The abstraction library provides a Harmattan style menu with
   toolbar for Harmattan, and a Silica style pulley menu for Silica.
5. The app designer choses a different paradigm altogether,
   abandoning use of tabs.

The whole thing becomes even more unmanageable if the abstraction
library is extend to support further Qt mobile platforms such as
Ubuntu, BB10, Android, iOS etc. Each of these will have different UI
paradigms / quirks, different backend libraries, app store rules etc.

The UI is particularly important given the small amount of real-estate
offered by even today's smartphones. So while from a development point
of view I might like the BB10, Sailfish and Android versions of my
app to have the same look and feel from common code, chances are most
users will want the apps to behave like other apps on their phone of
choice. (Swipes on Sailfish, back-button on Android etc.)

All of this means that more and more effort needs to be invested into
the abstraction library, and it may get to the point that more effort
is required for this then is saved from maintaining multiple code
bases for a given app.

But to answer your question: How can you help?

In the first instance some architectural thinking on the issues
outlined above would be invaluable. After that it depends on your
skills and what you would like to do as much as on anything else.

I have spent the past few months mainly focussed on the Harmattan
version of my app Landed (which uses the Harmattan flavour of
AbstractUI). Now that this app is "finished" and has been majorly
refactored with the aim of easing porting, I am back to porting it to
Sailfish Qt5 - for the moment still using AbstractUI.

Grüsse

Chris