We can implement ads and a donation function to both applications. Or maybe offer a ads free version for few cents. The important thing is, that there is a free full featured version.
The donation function would be okay imho, the ads would be against the idea of nextcloud since this means user tracking by the ad solution. And I wouldnât want that. 
3 Likes
mh yes the tracking thing is a problem. Youâre right, but donation will be good anyway, for Android and iOS.
1 Like
We will never ever put advertisement in any part of Nextcloud. 
Even if thereâs no tracking, ads are the most annoying thing you can do in any app, website or even on the street.
Stealing peopleâs time and bombarding them with bullshit is exactly what I fight against as designer. 
Optional donations from people who can spare something is the way to go. And people who can code contribute that, designers design, translators translate, documentation people document, people help each other. Thatâs what makes open source great, everyone can contribute.
And then there can be some companies making money off it by providing some real value like support, providing storage, etc. Not by butchering the application.
7 Likes
Another topic I wanna talk about is Nextcloud App integration in our Android app. For example I used the Owncloud note app but on my phone I had to open a File in my file hirarchy instead of getting a list of my notes. Never used other Owncloud Apps so I donât know how they solve the Android App integration.
I think we should invent a framework to create the possibility Nextcloud app developers could integrate their apps in our Android and iOS application as well. Maybe a Plugin architecture so we can add Plugins to our Android Application from Playstore or nextcloud store.
In perfect world people would use android library to access accounts. But app devs would also want to access other stuff like file list. I would be in favour to implement content provider which exposes multiple things. Eg ContentProvider is finished, but not merged into main repository.
1 Like
I second that approach! 
This would cover quite a lot of use cases.
Plus I already added a paragraph to the lib project on how to use jitpack to reference the lib from an app project and was also thinking about adding a deployment process to upload lib releases to the maven repo.
Ben wrote:
I know several people who are annoyed by the sync process of the android application. They have to sync every file manually. The main feature of an cloud application should be sync files with the cloud. maybe calendar and contacts too. Imho itâs not userfriendly, If that does not work automatically.
Just a note - our users actually like that the files DO NOT sync on Android - that theyâre just tombstones. It has to do with space availability on most of our phones. Not all of us have SD cards or 64GB phones. This should at least be an option to turn it off if the behavior changes. I understand thatâs not really WebDAV syncing, and that the Android client is therefore an anomaly of sorts, but the current functionality is perfect, at least for our users. I know weâre not the center of the universe.
I know that personally I want large files like videos to be moved from my phone to ownCloud/Nextcloud, but there are certain important, but small folders (such as particular project documents) that I wish would stay completely two way synced at all times.
Most of Android users are using SD cards, except flagship users. But yes youâre totally right, it should be configurable, that makes sense. 
And Iâm aware of that we are not the center of the universe, thatâs why I referred to other users who reported to me, that this behavior is not acceptable for them.
this behavior will be not easy to implement, but is imho very important. the configuration dialog should be as simple as possible but it should be also possible to configure every directory and file.
1 Like
Just did an informal survey here at work (weâre mostly on Android). Out of five of us in the office right now (not those in the field), only one of us uses an SD card. Out of five family accounts personally, none of us use an SD card. A good deal of Android phones still donât even accept SD cards. Some of us arenât running flagship phones and donât have SD capability.
It should absolutely be an option. The behavior youâre saying is unacceptable to you is our preferred, while the behavior youâre suggesting be the default would be unacceptable to us.
Iâm not sure what the default behavior should be though, I guess thatâs for the devs to decide. I just didnât want these statements to go unchallenged.
No I said it is unacceptable for many people who reported that to me. I was not talking about me in that case. Even it is my opinion as well, I agreed to your suggestion that it should be configurable.
Maybe we can check whether there is an sd card, if yes we can sync the files autmatically.
To answer several concerns:
This is how it currently works, it syncs only document structure, but you can have a file selected as âfavoriteâ and that file is synced together with document structure, if needed.
Pre android 6 implementation was done by me, but never merged into the app, waiting for beta testers and reviews. Post android 6 is a lot harder, first of you need to ask user for permission to read external storage, handle response, than look for configuration differences in app, then look for external (not simulated) storage, again ask for user permission, and finally you can write to SD 
XML? 
We should really get that checked out.
1 Like
That would then be a server matter at first with then upcoming changes on the client side due to the new data format. Question would then still be if this should be done b/c it would completely break the interface and thus existing clients (e.g. community notes Android client). And we probably wouldnât want that for now.
mh but imho it is better to implement all api breaking things as fast as we can, to make it easier for end users. They donât want several updates which are breaking the API, so maybe in the next major release most of that stuff should be done to create a stable API as soon as possible.
Am I missing something? Where does this XML come from and what is meant with it?
I Never said that 
You mean @jyaworski, but yes I donât like it either. It bloats up the communication process. A better technologie would be JSON or recently BSON.
1 Like