Will we still have the desktop [mac, windows, linux] & android, iOS apps under Nextcloud?
With the iOS app it’s a little bit more tricky because due to it’s license we’re not able to distribute https://github.com/owncloud/ios. We’re working on a solution for that as well and might be able to share some news on that front soon
The Android client is imho not really what a cloud user want as a cloud application. It would be better to sync files in background if user is on wifi. Therefore it is important to support storing the owncloud data on external storage.
So maybe it’s better to develop both clients from the scratch again.
Sure. There are always ways to provide a better product and more fancy features. But for the start it’s important just to offer feature parity. And then … well … then we have to sort out who is wanting to help with the Android app and how the development processes and so should work there
\cc @Andy, if you have ideas on how an open process for Android development can look like you’re very much welcome to share your thoughts in a new topic here.
There’s definitely been a lack of a proper definition of what is an ownCloud client. The Android client does very different things compared to the desktop clients. On Android I actually prefer using a generic webdav client rather than the ownCloud client.
Also note that the Android client has been suffering from a lack of proper documentation; most of its functionality is undocumented.
@Ben can you provide some more details on the Android client issue? For me (to some extend) the Android app does exactly what I (and probably many others) expect from a mobile app for a cloud storage:
- Instant Photo upload (which you can configure for wifi only)
I didn’t quite get the point you are mentioning about external storage. Do you mean on the server or the client side? The client side is able to do that in some areas (see the ownCloud android app PRs). So For the Android client I would rather suggest to use the existing one as a basis. Re-developing the complete client will take a while which might not be worth the effort (time wise)
So as far I understand you the general expectation would be to have some kind of feature parity on the clients as well as more documentation?
Can you go into more details on what you mean by that? I sure can but haven’t understood the question yet? I do have an opinion on how to kick things of and can open a new topic for that which I would consider a meta discussion (as in discuss the process).
@LukasReschke What is the issue with iOS? Looking at the repo it is GPLv3, shouldn’t that work (for a fork)?
Exactly that. Just describe what you would like and prefer and get the discussion starting. Input like that is always very welcome and we’ll do our best to implement it as best as possible.
@Andy Apple does not allow us to distribute it. See also http://apple.stackexchange.com/questions/6109/is-it-possible-to-have-gpl-software-in-the-mac-app-store. That’s what the ownCloud license exemption is for.
@LukasReschke More documentation would definitely be welcome. I don’t really like apps doing “something” when I click “somewhere”. I remember that when (a previous version of) the ownCloud Android app synced a folder, it actually copied the folder locally and then that was it, whereas the desktop client would keep (local and remote) folders in sync. That’s definitely something different.
I’m not sure how far feature parity should go. There’s probably no need to duplicate features provided by the platform, I’m thinking of cardDav support which is provided in macOS but not for Android. The Android client would benefit from cardDAV support, but for the macOS client it would be redundant.
@jknockaert cardDAV and calDAV would certainly be something which imho would great to have within the Android app even though other apps are available in the stores to cover this feature and some people prefere to have such feature separated using specialized apps while I am a all-in-one preferring person but this is a classic for feature prioritization and accepatance
I was not talking about all features the android client provides
Ok let me go deeper in details.
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.
With external storage I mean something like an sd card in your android device. As far as I know you can not place your owncloud data directory on external storage, but maybe I’m wrong. When you only have few GB left on the system, you don’t want all of your synchronized files on the internal storage but rather on the external sd card.
You’re totally right, develop every line of code again would be a waste of time. Therefore some classes should be reused. But a redevelopment could improve the speed, the usability and the design concepts. I would help at the end of summer when you have some code in your new github repository.
@Ben any support is always appreciated As for the storage location, as far as I know Tobias did an implementation for that and it is present in the beta version which contains most PRs especially his and mine that haven’t made to the stable/release (yet).
The product Owncloud (now nextcloud) is a great application and I don’t wanna miss it. Therefore I will support you guys the best I can.
Ah ok sorry didn’t know that the beta is able to do that. But anyway the beta is not on playstore
Maybe the nextcloud android application will be there soon and we can try out that feature.
Damn right. But we can do small steps, like adding the links in the app for example (as suggested before). If you and Tobias lead development for our Android app then I’m sure we’re gonna have a bunch of cool stuff.
Hope there will someday be a way to select which folders from the device will be synced.
Also a separate photos app would probably need to be created. Right now backing up, viewing and managing
photos from the phone & xxxCloud is quite unwieldy.
I think that’s one of the problems. The owncloud android app is not designed to be a filesystem manager like ES Explorer. I don’t know how but somehow we have to combine the qualities of a filesystem explorer and an cloud application to improve the user experience. But this is quite difficul because it is necessary to show the virtual nextcloud files and the local system files. So you have to scan the online directory and the local file system very often I think.
IMO Nextcloud clients should just make API calls to Nextcloud-on-the-server with a pretty UI (based on OS/theme) to glue it all together. Doing it this way makes it very easy to implement. A Nextcloud SDK, if you will.
I’m a heavy user of the Android app and this behaviour is something that really caught me off-guard when I switched from Dropbox to ownCloud. Having to manually sync files using a menu behind a long press is quite counterintuitive for a file sync app.
The only other annoyance I’ve found is having to do this once for every file to be synced/deleted, rather than being able to select multiple files at once. These little complaints aside, I’ve been quite pleased with the Android app.
that’s exactly what I mean and I hope we can change this behavior in the future.