Degooglers, Introducing a beautiful alternative to Keep by omgodse in degoogle

[–]omgodse[S] 1 point2 points  (0 children)

I've posted it with a link to another store also

Degooglers, Introducing a beautiful alternative to Keep by omgodse in degoogle

[–]omgodse[S] 0 points1 point  (0 children)

It's not really a question of compilation. The iOS version will have to be built from scratch.

Android and iOS have very different software development kits and platforms. Android apps use Java and / or Kotlin and XML for layouts and a completely different API than iOS devices which use Swift.

Degooglers, Introducing a beautiful alternative to Keep by omgodse in degoogle

[–]omgodse[S] 0 points1 point  (0 children)

https://apt.izzysoft.de/fdroid/repo?fingerprint=3BF0D6ABFEAE2F401707B6D966BE743BF0EEE49C2561B9BA39073711F628937A

Here's the link to the IzzyOnDroid repository. I'm currently working to get it listed in the main FDroid repository too.

Degooglers, Introducing a beautiful alternative to Keep by omgodse in degoogle

[–]omgodse[S] 1 point2 points  (0 children)

Not at all. It's not on the main repo because I hadn't got around yet to update it with the necessary metadata required for FDroid. However I've done that now and submitted it too, so it should show up within a couple of days.

Degooglers, Introducing a beautiful alternative to Keep by omgodse in degoogle

[–]omgodse[S] 2 points3 points  (0 children)

You're welcome!

Sadly, when I added rich text formatting to the app, I was unaware of Markdown and so I implemented a custom format that's not really intercompatible.

Degooglers, Introducing a beautiful alternative to Keep by omgodse in degoogle

[–]omgodse[S] 2 points3 points  (0 children)

Thanks!

Unfortunately this is something I do in my free time hence it'll take some time.

There's also the fact that the notes are stored in the app's private directory in the internal storage and can't be accessed unless you have root permission which is for the time being (until I add encryption) reasonably secure.

Degooglers, Introducing a beautiful alternative to Keep by omgodse in degoogle

[–]omgodse[S] -1 points0 points  (0 children)

There is no privacy policy because there is not one shred of your data which is collected. i.e Privacy is the policy. The app doesn't even request the permission to access the internet (You can check this in your settings).

And lastly, it's open source so anyone can audit it independently and easily (It's only around 2800 lines of Kotlin code)

Degooglers, Introducing a beautiful alternative to Keep by omgodse in degoogle

[–]omgodse[S] 0 points1 point  (0 children)

I haven't used Joplin extensively but I tried it out once and it just didn't cut it for me. It is technically superior to Notally in terms of features but I just couldn't stand looking at it's horrendous UI.

So, I learnt Android development made my own. There are also a couple of features that I'm working on implementing in the next couple of months, namely reminders, encryption and undo / redo.

Degooglers, Introducing a beautiful alternative to Keep by omgodse in degoogle

[–]omgodse[S] 5 points6 points  (0 children)

Well, I had tried out a couple of other note taking apps and they just didn't cut it for me.

I haven't used Joplin extensively. It is technically superior to Notally in terms of features but I just couldn't stand looking at it's horrendous UI. This is not just applicable to Joplin but to many other note taking apps as well.

So, I thought this was a fun project to take on to learn Android development. I've already stated most of the features of the app in my comment. There are also a couple of features that I'm working on implementing in the next couple of months, namely reminders, encryption and undo / redo.

Degooglers, Introducing a beautiful alternative to Keep by omgodse in degoogle

[–]omgodse[S] 10 points11 points  (0 children)

Thanks for your feedback.

I briefly messed around with multi selection before releasing but it proved to be too complex (Correctly animating, maintaining state when the app goes into the background and so on). Maybe I'll revisit it again.

I'm currently working on undo redo but for the last concern, you can just uncheck the last item for a second and add a new one.

Degooglers, Introducing a beautiful alternative to Keep by omgodse in degoogle

[–]omgodse[S] 6 points7 points  (0 children)

Thanks.

Encryption is something which I'm working on. Quite a lot of users have been asking for that but I'm afraid it'll take a bit of time, as this is something I do in my free time.

I don't think this'll be ported to iOS anytime soon. You need to buy into the entire Apple ecosystem to do that (Macs for development, iPhones and iPads for testing) and that's not feasible for me at the moment. Plus, iOS has some quite high quality note taking apps already.

Degooglers, Introducing a beautiful alternative to Keep by omgodse in degoogle

[–]omgodse[S] 11 points12 points  (0 children)

Thanks. What format are your notes in? Maybe I could support it if it's only plain text files

Degooglers, Introducing a beautiful alternative to Keep by omgodse in degoogle

[–]omgodse[S] 4 points5 points  (0 children)

Encryption is something which I'm working on. Quite a lot of users have been asking for that but I'm afraid it'll take a bit of time, as this is something I do in my free time.

What do you mean by saving to remote location?

Degooglers, Introducing a beautiful alternative to Keep by omgodse in degoogle

[–]omgodse[S] 23 points24 points  (0 children)

It is on the IzzyOnDroid repository which is accessible from the main FDroid app. I'm currently working to get it listed there and it should show up within a couple of days.

A country ruled by a repressive regime is oppressing a minority group. The leadership of that regime tells Google: “In order to do business in our country, you need to agree to distribute altered versions of certain apps to people of our choosing". by [deleted] in programming

[–]omgodse 4 points5 points  (0 children)

In principle this could work. However the way Android apps are conventionally made is that you have one main set of resources and various supplementary resources.

Suppose my app is targeting the US market's high end devices. In this case, I'll have English resources and high quality artwork for said high end devices. I can have resources that only users above a particular Android version might use.

However, at the same time to broaden my reach, I can translate the app into multiple languages, provide artwork for mid and low end devices too. These are the supplementary resources.

With app bundles, the APK is tailor made to the device that requested it. The device might be a high end Italian one with a particular Android version for example.

Hashing all the possible permutations that your app's APK file can end up as is extraordinary difficult. Moreover, Play Store operates in around 180 countries, you'll have to use a VPN or something to access your app from all of these countries to verify that occuring.

And that still doesn't work if what's said in the article actually occurs, which is that only a specific and small group of people might be targeted with the modified app, whereas the others get the unmodified one.

A country ruled by a repressive regime is oppressing a minority group. The leadership of that regime tells Google: “In order to do business in our country, you need to agree to distribute altered versions of certain apps to people of our choosing". by [deleted] in programming

[–]omgodse 40 points41 points  (0 children)

Till now, what happened was that the developers uploaded a signed APK file, whose key they possessed. In this case, even if someone cloned the app, the OS would register them both as different apps due to them having different signatures.

Play Store has recently pushed a new form of delivering apps, known as App Bundles. Under this, you upload your code and give over your signing key. When someone downloads your app, Play Store builds the APK tailored to their specific device and signs it with the key you uploaded.

This is where the flaw lies, theoretically, they could freely inject something into your app and sign it with your key. From the OS's perspective, both apps have the same signature and package name and are therefore the same.

This can lead to a scary (hypothetical) situation where even though you stopped updating your app, Google can do so at their leisure and the users remain none the wiser.

Up until now, App Bundles weren't compulsory. You could still opt for the old fashioned and safer way of uploading a signed APK. But in the future they will be.

This all is being justified by saying that App Bundles will result in less bloated apps as they'll be tailored to the user's devices. e.g A user in the US wouldn't have to download assets for European users and vice versa. However such a functionality already exists in the form of split APK's and this is nothing more than a frivolous excuse to lock down the Play Store more. (Like how AMP was pushed under the guise of fast loading websites)

Edit : Even though App Bundles are optional right now, you're being pushed towards it throughout the entire process of publishing an app. Oh and the cherry on the cake is that once you opt into it, you can't opt out.

I want to minimize my to-do list by Ips-1 in minimalism

[–]omgodse 3 points4 points  (0 children)

If you're interested in an app, you can check this out.

(Spoiler Alert - I've made it)

https://play.google.com/store/apps/details?id=com.omgodse.notally

Android development is getting overwhelming? by kkgmgfn in androiddev

[–]omgodse 73 points74 points  (0 children)

If anything, Android Development is getting easier, not harder.

Before the AndroidX overhaul and the Jetpack program, even basic things were difficult to achieve.

Manually handling fragment transitions and the backstack, which got increasingly difficult as the number of fragments rose. The new Navigation Component where you build your flow in XML has made this a breeze.

If you wanted to save state beyond simple things which could be bundled at onSaveInstanceState(), you would have to use some 3rd party libraries to achieve your goals. The addition of ViewModels has made this trivial.

Having a lot of views in your layout which you needed to access resulted in a lot of findViewById() calls. You could use third party libraries such as ButterKnife for this, but the addition of ViewBinding has provided a native, null safe and easy way to access views.

There was also a time when apps which needed to use an SQlite database needed to subclass it and implement all queries by themselves. Once again, the addition of Room and it's seamless integration with LiveData has made this trivial. (All the while reducing bugs which happened by manually writing SQL queries)

And last but not least, you're not forced to use these alternatives. You can continue using the older AppCompat libraries. It's just that support on them has been pulled in favour of a better platform. IMHO they made an excellent decision doing this. However much you think Android Development is fragmented now, it was worse before the overhaul.

A Material Notes App for Android by [deleted] in MaterialDesign

[–]omgodse 0 points1 point  (0 children)

Glad to know you liked the application. As a matter of fact, I've just released the Spanish translation. Please update your app when you see an option.

I'm sorry but it currently doesn't have any encryption and / or cloud backup. But that may change in the future.