I have just released an app to open/use Apple PassKit passes on ubuntu touch:

https://open-store.io/app/passes.s710

The app allows to import passes in .pkpass format and display them in a list, similar to iOS' wallet. Each pass will be shown with it's entire information, including the respective code which can then be scanned.

Core features:

• Import passes (.pkass files) into the app
• Share passes from within the app
• Fetch updates for a pass (in case it provides a webservice for updates)

Feel free to leave comments, and let me know if you encounter any pass which won't work with the app.

Got it, after googling even more. Some guy at the QT forum revealed:

   Connections {
      target: Qt.application

      onAboutToQuit: {
         audioPlayer.stop()
      }

This works

Teaser:

When trying to switch to UT, one of the blockers for most people could be the messenger apps, especially WhatsApp.

I personally will be unable to pass on WhatsApp, since I have too many contacts there, who are not willing to use other messengers. In addition, basically every organization of group events (birthdays, vacations, etc.) takes place in WhatsApp groups.
This forces me to keep on using WhatsApp, although I would like to replace it.

Now when making the switch to UT, this would mean I will need some sort of replacement, or ways to access my WhatsApp chats by other means.

Currently, I am aware of 3 possible solutions:

• Use WhatsApp web
• Use waydroid + WhatsApp native
• Use some sort of bridging (e.g. matrix)

I have tried all 3 of them, and found that all 3 of them are sub-par, and rather a pain to use than good.

• WhatsApp web is slow, not a real app, and not feature-complete.

• Waydroid can't be kept running 24/7 since it consumes too much battery. Also, its not (yet?) very well integrated, means you will always have a full android window.

• Matrix bridge works in a way, I have this running on a private home server for over a year. While it suddenly stopped syncing (for no obvious reason) during several months, and suddenly continued to sync (for no obvious reason), it basically allows me to chat with WhatsApp contacts using a matrix messenger (currently using Cinny). However, it has a whole bunch of disadvantages; matrix + bridge setup is overly complex, their documentation is severly lacking/incomplete as well as confusing, matrix will update year-old chats every now and then with some meaningless events ("Your security code with XXX changed"), audio-messages don't work at all.

So the question is, what is your solution for using WhatsApp on UT, and how happy are you with your solution?
(And please, for the love of god, don't spam this topic with "Just don't use WhatsApp" and the likes).

One thing that actually came to my mind recently was about the recently introduced European Union guideline for big messengers to force them to provide interoperability between messengers. E.g. WhatsApp must connect to Telegram, to allow WhatsApp chats within Telegram and vice versa.
Would this be a potential approach which was viable for UT also? So imagine we had an official UT messenger, and we could integrate with WhatsApp directly, this means we would have a native WhatsApp client? What you guys think about this?

... has just been published to the store:
https://open-store.io/app/scooter.s710

Its a port of my existing SailfishOS app, now its available on UT.

The app provides the following features:

• Log into an existing Bird account using E-Mail/confirmation code
• Show profile details
• Show scooter locations and restricted areas on a map
• Ring scooter
• Unlock scooter / start ride by scanning the QR code on the scooter
• Show pending/active rides which have not yet been stopped

This means that an existing Bird account with associated payment information is needed. It is not possible to create a new account with my app (use official iOS/android app).

Since undocumented APIs are used, there are several limitations. While it is perfectly possible to unlock scooters and take a ride, it is not possible to:

• coupon codes / ride passes can neither be displayed nor used. This means that even though a user buys a ride pass for free unlocking on e.g. iOS or android, using my app will not consider this, and the user will be charged more than necessary. I think this is caused by a recent change in the API, since some weeks ago the API would return the actual cost as well as "cost_without_coupon" when ending the ride, and charge the discount price, which no longer is the case.
• price information is displayed in USD, regardless of the user's country
• no interaction with the profile/payment information is possible, neither is the creation of accounts
• group rides and purchasing ride passes is not possible

If anyone is good in reverse engineering and wants to help, contact me

I have contacted Bird (as well as a number of other scooter providers), asking for help/documentation of their API in order to provide a better user experience, but I am not that optimistic.
Bird is the only provider of electric scooters I found where parts of the API are documented, including scooter unlocking/riding, however in case I get a response from other providers, or anyone comes up with API endpoint documentation for other providers, I can add them to the app.

In case errors occur during app usage, theres a log view in the settings, which can be used to send logs to me which might help analyze issues.

I added:

{
    "policy_groups": ["location", "networking"],
    "policy_version": 16.04
}

And now the map works as expected. Thanks again.

@emphrath said in How to create a plant identification app for ubuntu touch?:

I thought that was hilarious. Got another answer I wanted to share since it s outta my field of competence:

"1. Don't you think supporting Ubuntu Touch using the website is enough : https://docs.ubports.com/en/latest/appdev/webapp/index.html

2. the mobile app is made using React Native, unfortunately, https://github.com/status-im/react-native-desktop-qt is no longer supported but maybe there is an alternative?"

What do you think ? What should I answer ?

Didn't get to this until now. Give me a day or two, and I will see what kind of app I can come up with. Will be a native UT app.
In case it's enough, it would be maybe worthwile offering it to them and/or asking for improved API usage agreements.

@emphrath said in How to create a plant identification app for ubuntu touch?:

@s710 Wow, awesome. I guess it won't be using ReactJS then ? Do you think I should let them know sth is being worked on native-wise and pass along your suggestion of extended API rights ?

Correct. I have a working prototype, which is able to pick images from your camera or gallery, and then use their API to identify it. Currently I am working on displaying the results / designing the UI for the results.
As I don't have time to work on it today, I would say by the end of tomorrow I will be able to provide screenshots of the app, which you could then send them if you want.

Basically, there are no technical issues or blockers here, its just a matter of time to get the UI nice and polished now.

Great!

I think I forgot to add a function which either converts images (e.g. PNGs) into jpeg, or warn the user. I think Pl@ntNet only accepts jpeg. This might lead to unspecified errors when someone tries to upload non-jpeg images.

Gonna add this soon.

@emphrath said in How to create a plant identification app for ubuntu touch?:

@arubislander Well how do they make their own android app work then ? I don't get it.

Yeah well, maybe they're using non-public APIs. Those, of course, can also be reverse engineered from the binary.
I am no expert in reverse engineering, but I was told that virtually anything can be reverse engineered with enough efforts. For example, someone reverse engineered the HTTP APIs used by the Bird Scooter app (which, btw, enabled me to make a scooter app).

Unless you're using a dedicated authentication (user must login within the app), there is virtually no way of publishing something secure, you simply cannot ship credentials/hidden stuff. Of course, this is from a pure security perspective. The owner might still decide to ship apps like this and rely on no one caring about reverse engineering, which might be an acceptable risk.

In the end, it completely depends on what Pl@ntNet wants to do. I just wanted to point out that if I was given a dedicated API key, and Pl@nNet would increase limits for this single key, I would need to ship it within the app, which would be insecure per design. Of course, I can try to occlude it as best as I can, but it won't be bullet proof. If Pl@ntNet accepts this approach, I don't see any real issues, since I guess that not so many people would be that eager to get into possession of a Pl@ntNet API-key with increased limits so that they would actually take the efforts of reverse engineering it out of my app.

I am the author of the Scooter app (https://open-store.io/app/scooter.s710), which supports operating Bird eletric scooters.

I have support for another provider in the works, and therefore needed to also change Bird-related code.

However, unfortunately, Bird withdrew from my hometown, so I no longer have accessto Bird scooters to test my app.

Therefore I want to ask if there was someone in the community with access to Bird scooters & UT phone willing to help me test the existing Bird functionality of my app? Basically I would supply an updated version of my app, and it should be tested whether or not searching for scooters, locking/unlocking and so on still works as before.

Okay nevermind. Although the bootloader was already stating "DEVICE STATE - unlocked", and every reboot remindst of the bootloader being unlocked, I had to do fastboot flashing unlock_critical (which would ask again if I wanted to unlock the bootloader), and then the flashing tool for FF4 would run fine.

Android was successfully reinstalled.

Okay, so it turned out that all the time I had

MainView {
   id: root
   objectName: 'mainView'
   applicationName: 'myapp.s710'
   automaticOrientation: true

//   width: units.gu(45)
//   height: units.gu(75)
   width: units.gu(100)
   height: units.gu(200)

Because when running as clickable desktop, the window would be tiny otherwise. However I never noticed a difference when deploying to the phone, so I thought it was okay.

However, after I had just set QGuiApplication::setAttribute(Qt::AA_EnableHighDpiScaling); - which didn't have any effect - I also changed back the MainView size to 45/57, and voila, now the contents of the webview scale correctly, same as in the Morph browser.

Long story short:

• no need to set the user agent
• set QGuiApplication::setAttribute(Qt::AA_EnableHighDpiScaling);
• leave MainView dimensions set to units.gu(45)/units.gu(75) (which is the default after clickable create)

I also observe some kind of slow/laggy behaviour on the Volla Phone. Compared to this: https://www.youtube.com/watch?v=LVkOWclo52c
It seems like my Volla just performs worse. For example, the long-swipe from the right to show all open apps is super slow, it looks like it is rendered with 1-2 FPS.

Also the overall experience is okay-ish, but not as fluent as other devices I have dealt with (non-UT), except for my SFOS device. E.g. typing on the keyboard sometimes also feels a bit laggy (still in the okay-bounds I would say though).

I have no other experience with Ubuntu Touch, but also apps (even very basic ones) open only after a delay of 1-3 seconds, which is really a pity. For example opening UT settings takes like forever.

I also have an XPeria 10 ii running SFOS, and while its overall performance is worse than the Volla Phone running UT, it is still capable of opening certain apps instantly.

I thought that the Volla Phone hardware should be quite good/okay, so I'm a bit disappointed by the performance on UT.

I was hoping that the latest update would bring some improvements, but unfortunately I am noticing no difference whatsoever.

@applee My response was not meant to be offensive, rather curious. I am new to UT, and just need to figure things out.

I am currently working on porting my SFOS Scooter app to Ubuntu Touch, and I am basically done. The only feature which is missing is the scanning of QR codes.

In the app, I am using the awesome qzxing library, which allows to use video filters for QR code recognition. Unfortunately, on Ubuntu Touch, it will not work. I have reported the issue already here, but I'd like to get this over with, so I am asking for your help.

The core issue is, that qzxing relies on converting QVideoFrame objects to QImage by mapping the raw data into memory using QVideoFrame::map. However, on Ubuntu Touch, this very function does not work, because the image is saved as OpenGL texture in the QT internals. The same is the case for e.g. Android, which is why there is suggested solutions which can be found on google.
However, I am unable to come up with a working solution, most likely because I am neither familiar with OpenGL, nor with image/video formats.

I have asked for help already at stackoverflow and the qt forum, unfortunately no one answered yet.

I am aware that there is a QR code scanning app in the open store, and that I could copy the solution used in that app, however I'd like to stick with qzxing for two reasons:

• I find the use of video filters to be the more elegant solution
• I can maintain a somewhat compatibility to my SFOS app which helps keeping maintainance efforts low

So if anyone would volunteer to support or maybe knows the solution, please let me know. The relevant code parts would be here.

Maybe I am also missing the obvious, and qzxing can already be used in UT and I'm just missing something, in this case I would also extremely appreciate your help.

My overall impression on the Volla Phone is also that is somehow laggy in general.

• E.g. typing the password for unlocking the device already lags a bit for me. It might not be noticeable for some people, but compared to e.g. my iPhone, the keys definitely lag behind the touch. Its not unbearable, but it adds to the non-fluent overall feeling for me.
• Same is true for the long swipe from the left, which shows the opened apps. It will open in a slow/laggy way
• Scrolling in the browser also a bit of stuttering. You can best see it if you "push" the scrolling a bit then let go with your finger (so it continues a bit to scroll). The animation will not be fluent.
• Opening the settings app takes 4-5s
• Opening teleports takes around 3s
• Opening the gallery app takes more than 30s (although I must confess that I have copied several hundres of photos over from my iPhone)
• Opening Dekko 2 takes around 3-5s
• Opening the calendar app takes around 3-4s
• Opening the notes app (with no notes saved) takes around 3s

In general, the app drawer seems to react only after a short delay; e.g. when your finger touches an app icon, there is no immediate reaction for about 0,5-1s, which already results in a rather non-fluent/laggy user experience.

I have only 2 other devices to compare: my iPhone 11 pro, and a Sony XPeria 10ii which runs SFOS.

On the iPhone, all apps will open almost instantly, and I am unable to measure any delay for most apps. If, at all, the general pattern on iOS seems to be that the UI of the app is presented instantly/as fast as possible, so that the UX feels quick and responsible, but then the app may start loading content (e.g. Telegram shows the locally cached apps, but then connects to the network and loads updates).

On SFOS, some apps open really quickly, others also have a short delay, but overall it seems to open quicker than on UT/Volla Phone. The browser on SFOS is unusable, both on the performance side and on the tech side (outdated, does not support many websites), so I cant compare. Other stock apps however seem to run decently.
The overall handling seems to be rather fluent/okay-ish though. Swiping to close apps is fast, switching apps and opening the notification screen is good.

As for the app opening times, I have just measured them on my Volla Phone, maybe someone can add their respective opening times on other devices. I have no other Ubuntu Touch device to compare, so I don't know if those times are to be expected.

I have chosen the Volla Phone back then because the hardware seems to be decent, and the design is pretty, and I would love to use it (and I am going to start once waydroid makes it way to a stable release, and BT/Wifi works), however I would really love to see the Volla Phone perform better.
Since I have no other device to compare, I can't judge if my above user experience is to be expected on Ubuntu Touch in general, or if in fact there is performence issues on the Volla Phone. It the latter was the case, I would love to see the situation improved in the future.

No worries, I'm aware of that. I really just wanted to know what possibilities already exist.
I'm a developer, and I started to work on UT apps, so maybe in the future I'll come up with something. Depends on time and energy though, already got a lot of ideas popping up in my head.
But for now I'll port my SFOS scooter app to UT, and then lets see.

@aarontheissueguy said in Wallet/Passes app for UT:

@s710 Great work! We really needed something like this. It would be great to allow importing QR and Barcodes (maby via tagger) and make it possible to create custom passes.

A corresponding issue was opened on github:
https://github.com/patrickjane/ut-passes/issues/5

I'm going to check this and maybe put it into the app in case there was a feasible solution. Have not yet heard of this, so I need to check this out first.

@arubislander said in Scroling application on Volla Phone is very sluggy:

@s710 said in Scroling application on Volla Phone is very sluggy:

I have copied several hundres of photos over from my iPhone)

I can't help but wonder if the sluggishness you experience has anything to do with the amount of photos you copied over. This is not to excuse the performance of course, just looking to explain why not every volla phone owner has the same experience...

Yeah, definitely! I have copied over a crapload of photos. I think the thumbnailer does not cache, and thus results in a really slow behaviour.

On the iPhone, I have never seen any kind of loading/missing thumbnails at all. I just checked, I have 6.500 photos on the iPhone. I can scroll through them as if it was only 10. No stuttering, slow loading whatsoever. Of course, hard- and software performance of some iPhone 11 pro cannot possibly be compared to a VollaPhone running UT.

On SFOS, the gallery also performs much better, albeit it does not reach iPhone performance.

On UT, it seems like the gallery just does ls ~/Pictures and then allPictures.forEach(p => p.generatePreview) (pseudo-code). That is, there does not seems to be any intelligent/proper handling for a bigger amount of stored pictures/photos.

I admit that copying over 28GB of photos to the VollaPhone is not exactly the standard use case for most users. However it points out that UT is having issues with a large number of pictures, which other users may experience also sooner or later.

I have no clue how android performs, since I never use android phones. However I remember from my old Sony times that the gallery back then also had some drawbacks in terms of missing thumbnails / stuttering while scrolling the gallery, and I have seen similar on android phones of friends. Maybe it is indeed only possible to deliver good gallery performance on top-tier hardware, no matter what the OS is.

[edit] And I might add that I am aware of the fact that my iPhone had the ability to create thumbnails one by one for all the 6.500 photos, while other phones (be it UT or SFOS) where I copy those photos to must stem the efforts of creating thumbnails for all 6.500 photos at once.