search

jimmejardine / qiqqa-open-source

The open-sourced version of the award-winning Qiqqa research management tool for Windows
GNU General Public License v3.0
366 stars 60 forks source link

App for Android #412

Open DanBarral opened 1 year ago

DanBarral commented 1 year ago

Hi! Im new to the community but im doing a doctorate in history and this software is a potencial gamechanger in the field. I am not a coder but i would love to support in everyway i can. Which leads me to posting this note about the Android version. I am very excited to be able to intranet my research to my tablet but the old version easily available for android is only a pdf reader which cant sync since i cant create an account anymore. I saw ppl discussing coding for android so where can i find an .exe to install the latest version possible. Also, i decided to try the version 8.3 with a small sample of my research and try to report back any bugs i may find. Thank you all so much for this wonderfull work. I am a post pandemic mendeley orphan in humanities and i was so sad to have to go back to EXCELL... You all really gave me hope.

GerHobbelt commented 1 year ago

We haven't planned an Android/iOS version yet, alas.

Back when Qiqqa was a commercial product, there was mention of an Android beta version being available, but I only had bought the desktop application license myself, so I wondered what it was. Thanks for reporting: I guessed it could not be much more than a glorified PDF reader that connected to the person's Qiqqa Cloud store, but this cinches it as that codebase was never open-sourced.

While I can see the use for Qiqqa on mobile / tablet, the problem is a tad complex:

  1. Storage limits and computing + network restraints: Using my own situation as a benchmark: personally, I have large libraries, and while modern phones offer 64GB Flash storage (or even more), the total required storage for those PDFs, their OCR/text exports and constructed FTS (Full Text Search) Index are considerably more in my case.

    Of course, reaching such sizes didn't happen in a day and using Qiqqa for a research project would expect smaller counts and sizes, but phones still have noticable limits and performance restraints when compared to desktop applications.

    The usual approach out there is to store and 'do' everything on one or more server clusters (CDN, ...) where the mobile app is a more-or-less fat client to the cloud service. That's great for businesses (SaaS; systemic recurrent service fee to keep the business afloat) but I'm loath to make Qiqqa dependent on any cloud storage or (rented) server rig of any kind (AMS, Azure, heroku, ...): cloud storage is fine for backups and multi-user / sharing setups, but those should be the prerogative and choice of the end-user, not a requirement of the Qiqqa design. Which results in the need to keep (synchronized) local copies of those PDFs, etc. that make up your library on each node where Qiqqa will run.

    I'm pondering "fixing" this lack of mobile support by making 'desktop Qiqqa' a server, which can, when the end-user wishes so, be accessed via the Internet. That would allow the use of arbitrary (internet-connected) remote workstations and mobiles -- the requirement of those then being that they must be "on-line" all the while they are used.

    This is an option, that will result from the work planned this year. This is, as with any server connection, a security risk and requires administrative skills, though. (Which is usually taken care of by the company selling you any SaaS / app. Qiqqa does not have a business backing it, so that becomes end-user task+risk, when enabled once it becomes available. Hairy stuff. :wink:

  2. memory and programming restraints: As both the Android and iOS mobile platforms each have their own special programming restrictions for what is accepted into their App Stores, any Android and iOS app needs to be developed in ways that are, at least in part, dedicated to said platform. I'm already spread pretty thin, so this is only a potential reality when others are chime in with significant dedication and dev hours.

    Which is another reason why I consider the way forward through, instead, using a generic web application (SPA-like) that's based on using your web browser. While this is feasible, certain functionalities cannot be achieved that way, in particular the Qiqqa Sniffer workflow. Something simpler and functionally limited might be possible for platforms which cannot do multiple parallel interconnected webview instances with different security contexts, but I haven't looked very deeply into this for mobile, as the Sniffer workflow demands a large visual work area by design/necessity -- and while mobile screens may sport large DPI numbers, you'd need a microscope or severe myopia[^1] to make the up-to-10" display diagonal enlarge to something that's fit for a human to perceive a large amount of data simultaneously. Of course, tablets have larger screen diagonals, so for those only the 'dedicated software development effort required' part of this argument stands.

[^1]: while not visible in my avatar, my eyes are at -11 (~ effectively blind without contacts or glasses), but even that level of myopia doesn't make me a happy user of mobile screens for large amounts of information content. 1080p or 4K alone doesn't deliver a useful and easy experience. :wink:

FYI: the planning for Qiqqa is to dedicate this year (as much as I'm available) to a (partial) rewrite: several major components have enough persistent issues that, after long deliberation, I regret this is the most feasible way forward for me. That means that I expect/hope to have a new Qiqqa by the end of 2023, which would be webserver technology and portable GUI tech based, so we can start to support the other big player in the room: Linux desktops and laptops. From there, there's a potential inroad for mobile/tablet, as I intend to redo most of the UI in web tech, a.k.a. "web pages", which would be accesible/usable in a modern browser.

But be reminded: we're still at the early stages, concentrating on the back-end of the application, so there's still a long way to go before this "future music" will approach reailty!

DanBarral commented 1 year ago

Thank you so much for your detailed response! I am very pleased to know that thinking of a way to web connect and maybe portable devices is a possibility for this year’s development and very pleased to know that you are expecting a release this year still! About the security risks: maybe rewriting the Qiqqa manual to better reflect the stage of development and better guide the new user on how to defend himself and make the most out of his qiqqa experience. Cause the manual is very outdated. Of course i understand you have a lot on your plate and this would be a suggestion for when the team reaches a stage where everything is more stable and ready for a larger user base. I am now using the 8.2 version which is more stable and the highlights work beatifully. I am very eager to try and use qiqqa on historical documents to build a database. i shall report back if it works.

Em dom., 16 de abr. de 2023 às 12:45, Ger Hobbelt @.***> escreveu:

We haven't planned an Android/iOS version yet, alas.

Back when Qiqqa was a commercial product, there was mention of an Android beta version being available, but I only had bought the desktop application license myself, so I wondered what it was. Thanks for reporting: I guessed it could not be much more than a glorified PDF reader that connected to the person's Qiqqa Cloud store, but this cinches it as that codebase was never open-sourced.

While I can see the use for Qiqqa on mobile / tablet, the problem is a tad complex:

1.

Storage limits and computing + network restraints: Using my own situation as a benchmark: personally, I have large libraries, and while modern phones offer 64GB Flash storage (or even more), the total required storage for those PDFs, their OCR/text exports and constructed FTS (Full Text Search) Index are considerably more in my case.

Of course, reaching such sizes didn't happen in a day and using Qiqqa for a research project would expect smaller counts and sizes, but phones still have noticable limits and performance restraints when compared to desktop applications.

The usual approach out there is to store and 'do' everything on one or more server clusters (CDN, ...) where the mobile app is a more-or-less fat client to the cloud service. That's great for businesses (SaaS; systemic recurrent service fee to keep the business afloat) but I'm loath to make Qiqqa dependent on any cloud storage or (rented) server rig of any kind (AMS, Azure, heroku, ...): cloud storage is fine for backups and multi-user / sharing setups, but those should be the prerogative and choice of the end-user, not a requirement of the Qiqqa design. Which results in the need to keep (synchronized) local copies of those PDFs, etc. that make up your library on each node where Qiqqa will run.

I'm pondering "fixing" this lack of mobile support by making 'desktop Qiqqa' a server, which can, when the end-user wishes so, be accessed via the Internet. That would allow the use of arbitrary (internet-connected) remote workstations and mobiles -- the requirement of those then being that they must be "on-line" all the while they are used.

This is an option, that will result from the work planned this year. This is, as with any server connection, a security risk and requires administrative skills, though. (Which is usually taken care of by the company selling you any SaaS / app. Qiqqa does not have a business backing it, so that becomes end-user task+risk, when enabled once it becomes available. Hairy stuff. 😉

2.

memory and programming restraints: As both the Android and iOS mobile platforms each have their own special programming restrictions for what is accepted into their App Stores, any Android and iOS app needs to be developed in ways that are, at least in part, dedicated to said platform. I'm already spread pretty thin, so this is only a potential reality when others are chime in with significant dedication and dev hours.

Which is another reason why I consider the way forward through, instead, using a generic web application (SPA-like) that's based on using your web browser. While this is feasible, certain functionalities cannot be achieved that way, in particular the Qiqqa Sniffer workflow. Something simpler and functionally limited might be possible for platforms which cannot do multiple parallel interconnected webview instances with different security contexts, but I haven't looked very deeply into this for mobile, as the Sniffer workflow demands a large visual work area by design/necessity -- and while mobile screens may sport large DPI numbers, you'd need a microscope or severe myopia1 <#m_-3633703683440113188_user-content-fn-1-54b303c4b8a5650fb58219648b56e8f4> to make the up-to-10" display diagonal enlarge to something that's fit for a human to perceive a large amount of data simultaneously. Of course, tablets have larger screen diagonals, so for those only the 'dedicated software development effort required' part of this argument stands.

FYI: the planning for Qiqqa is to dedicate this year (as much as I'm available) to a (partial) rewrite: several major components have enough persistent issues that, after long deliberation, I regret this is the most feasible way forward for me. That means that I expect/hope to have a new Qiqqa by the end of 2023, which would be webserver technology and portable GUI tech based, so we can start to support the other big player in the room: Linux desktops and laptops. From there, there's a potential inroad for mobile/tablet, as I intend to redo most of the UI in web tech, a.k.a. "web pages", which would be accesible/usable in a modern browser.

But be reminded: we're still at the early stages, concentrating on the back-end of the application, so there's still a long way to go before this "future music" will approach reailty! Footnotes

1.

while not visible in my avatar, my eyes are at -11 (~ effectively blind without contacts or glasses), but even that level of myopia doesn't make me a happy user of mobile screens for large amounts of information content. 1080p or 4K alone doesn't deliver a useful and easy experience. 😉 ↩ <#m_-3633703683440113188_user-content-fnref-1-54b303c4b8a5650fb58219648b56e8f4>

— Reply to this email directly, view it on GitHub https://github.com/jimmejardine/qiqqa-open-source/issues/412#issuecomment-1510417064, or unsubscribe https://github.com/notifications/unsubscribe-auth/A67ER6P4CDI44JVZAN4KQP3XBQHYPANCNFSM6AAAAAAWTLTEMA . You are receiving this because you authored the thread.Message ID: @.***>

IMehrn commented 9 months ago

I am an old user of Qiqqa! I was eagerly paying for the service and had no problem with that as long as it was meeting my demands. Recently I bought a tablet (with android system) mostly because of the great feeling of the pen and how it helped me go paperless for lots of my works. From then I feel the need to sync between several devices as a serious issue. While I still do most of my work behind my Laptop and PC with big screen, I enjoy the feeling of having a digital note now and then while having a coffee, going to another office, moving to a sofa, etc. In short, I think being able to do something on my android device and being able to do more on it (not just viewing the pdfs), is more important than knowing that Qiqqa also supports Linux systems.

I did not fully understand why you talk about storage and memory limits, as the goal (in mind) is that everything is saved online (for me, on Dropbox), synced almost simultaneously, and I open files one by one on the tablet (not all the library at once).

Hope this feedback would change your mind about priorities of the project.