Am 23.06.16 um 08:57 schrieb Shawn Rutledge: >> On 23 Jun 2016, at 07:15, ekke <e...@ekkes-corner.org> wrote: >> >> thx Maurice, >> >> Am 22.06.16 um 12:22 schrieb Maurice Kalinowski: >>>> Highest prio from my personal perspective: >>>>>> - Background processing API >>>>>> - In-app Notifications: local, remote >>>> + add Windows Store to Qt Purchasing module >> there's more missing: >> - avoid flicker for android apps out-of-the-box > What does that mean, just the initial appearance at startup? yep. would be great to start Android Apps without flicker by default. Now I must follow instructions like this: https://medium.com/@benlaud/complete-guide-to-make-a-splash-screen-for-your-qml-android-application-567ca3bc70af#.demzldbe9
> My pet peeve is that startup of Qt Android apps takes too long, compared to > Java apps. Ironically it's Java apps that are too slow on desktop platforms. > So I just wish I had a modern Qt-based phone, so that there’s one copy of > the libs in memory already. Apps would be small and fast. yep :) How fast this can be I know from BlackBerry10 Cascades/Qt/QML apps. But I have to look forward and provide x-platform apps for Android/iOS (perhaps W10 later) > >> - easy way to 'share' content with/from other apps (Intents, Deep Linking) >> Android, iOS >> such common use-cases should be abstracted and available via Qt API > Yes but it should be good, portable, future-proof API, to be worthwhile. > Ideally even portable between desktops and mobiles. It’s hard to predict the > future, too. There is a disconnect that on desktop platforms you share by > saving files in one application and re-opening in another, or via the > clipboard, or drag-and-drop, whereas on mobile platforms this stuff got > re-invented. I’m not sure if it’s an improvement: applications seem mostly > isolated now, effectively. Not that I’ve tried very hard to use a tablet for > office-y stuff, but I’m not sure if everything that was possible on the > desktop is possible on those platforms. If you extend the platform to > include cloud services (since not all data is even stored locally, I guess > it’s supposed to mean that inter-app sharing must include sharing of access > to data which is stored only on the cloud), do you trust them: are they > secure? are they going to still be there in a few years? will they continue > to have a gazillion non-interoperable ways to do similar stuff? How much > abstraction can we do, to make sharing locally or via the cloud look similar? > Would you dare to start a university degree program for example, and do all > your work only on a tablet? If you do that, can you still open anything that > you did in a decade or two? If the inter-app sharing mechanisms are > hindering people from getting work done, maybe they will be re-invented > again? So it seems hard to create APIs now that won’t look foolish in > retrospect later on. > > The file abstraction is nice because of being so universal. Even cloud > storage (with offline caching) can be done by making it a virtual filesystem. > Yet the file abstraction does seem long in the tooth, because we no longer > rely on hard disks as much, and installing flash memory as a “disk” instead > of “memory” is so arbitrary - it will end some day, especially if most memory > ends up being non-volatile eventually. But what is the long-term-stable > replacement for the hierarchical filesystem? Will we keep using it just > because it’s such a human-friendly metaphor? Or will sharing between all > apps end up looking more like today’s mobile APIs, where you first have to > open one app, and select the data, and “send” it to another; or, one app > invokes another to “pull” something? I guess the reason is that active > transfer between apps which are both running at the same time is deemed more > secure than passive file-reading. Or is there another reason? But the > protocols for that data transfer seem like shifting sand to me. from my enterprise customers requirements for x-platform android/ios: * support for incoming intents: employee opens a file (pdf, image, ...) and can open this one with Qt App to upload to server or so * support for outgoing intents: employee downloads file from server, then wants to open this one in Acrobat to read pdf, etc there are more use-cases for open-in-map (Google, here), open Phone-Call from phone-number, ... For my customers security is no question because app is running on BES12 server and AndroidForWork / SamsungKNOX on Android and secure-VPN-connection on iOS 9.x - so the app has only restricted access inside work data > > https://bugreports.qt.io/browse/QTBUG-36015 has links to some lower-level > tasks like support for intents, anyway. > thx mentioning this. will read through and add comments / bugreports. -- ekke (ekkehard gentz) independent software architect international development native mobile business apps BlackBerry 10 | Qt Mobile (Android, iOS) workshops - trainings - bootcamps *BlackBerry Elite Developer BlackBerry Platinum Enterprise Partner* max-josefs-platz 30, D-83022 rosenheim, germany mailto:e...@ekkes-corner.org blog: http://ekkes-corner.org apps and more: http://appbus.org twitter: @ekkescorner skype: ekkes-corner LinkedIn: http://linkedin.com/in/ekkehard/ Steuer-Nr: 156/220/30931 FA Rosenheim, UST-ID: DE189929490
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
