What is Reddit's opinion of
Realm?
From 3.5 billion Reddit comments
➔ Realm website
By popularity on Reddit, this Service is:
100 reviews of this app found across Reddit:
The article is really just some words tossed around this report: https://realm.io/realm-report/
I don't see any links to data or methodology. "Percent of developers" using Kotlin is at 14.3% (up from 7.4% in only 4 months). Where is that population coming from? How is it being measured? I see all sorts of other reports about Java growing and being bigger than ever before. The projection also looks weird. What is their method of project? Over the projection's period of time, the population will change. What population are they talking about?
Kotlin > Java in my eyes as a programming language, but these sorts of "reports" are opaque, and thus, untrustworthy.
For more information on the background of this subject, as well as stories told of the hearings, I recommend this talk I gave at AltConf.
https://realm.io/news/altconf-jay-freeman-dmca-digital-millennium-copyright-act/
For Android devs using only the database, this is probably the most interesting stuff:
Realm Studio for Mac, Windows and Linux: https://realm.io/products/realm-studio/
Lists of Primitives support: https://realm.io/docs/java/latest/#lists-of-primitives
RxJava 2 support: https://realm.io/docs/java/latest/#rxjava
Disclaimer: I work for Realm
Just to clear up some errors in your post.
- Realm does use APT to generate proxy classes, but they are invisible to the user.
- You don't need to extend a base class if you don't want to: https://realm.io/docs/java/latest/#realmmodel-interface
- Realm is not based on SQL, and we are faster all around: https://github.com/realm/realm-java-benchmarks
- We are an object database. So you just model your objects in Java and it just works because we support links between objects directly in the database. m:n tables doesn't exist when using Realm.
- Realm lazy-load all data, so you can query for a million objects without being worried about memory usage. Semantically you can think of our RealmResults class a type safe cursor, but it is completely hidden from you.
- Realm is an MVCC database with each thread having a consistent view of all data. This means that the thread issues you mention simply cannot happen with Realm. Only constraint is that that Realm Objects/Results are thread confined.
Limitations in your context is probably:
Include native codes. With APK split it still adds about 800k to your APK
We don't support subclassing our models yet. Composition over inheritance for now.
Given the requirements you listed, it sounds like you should give us a second glance, but up to you :)
I think Kotlin has been getting mindshare lately because of a few things:
- Its almost at 1.0 and things should be settling down
- 'Kotlin in Action' MEAP is now available from Manning - every country needs an airport and its own beer; every language needs a book from its creators
- Many developers are completely fed up with Google's ineptitude of getting Java in shape on Android, and its the most practical alternative JVM language for that platform with a slim runtime and excellent Android Studio / Intellij integration & tooling.
I think Android is the strongest reason for the uptick in Kotlin lately - they were there during a critical window of opportunity saying "we are the Swift of Android". For example, at a recent droidcon, this presentation was given:
Kotlin: A New Hope in a Java 6 Wasteland https://realm.io/news/droidcon-michael-pardo-kotlin/
So Kotlin gets lots of exposure among Android devs.
I'm not sure if this would completely solve your problem of writing queries, but SQLDelight will generate type safe apis to use from your kotlin code and provides some code completion when writing the queries. Otherwise if you're not tied to SQL, can always check out an orm like realm
To piggyback off this comment, this talk by Jake Wharton spends the early part of it talking about some of the challenges facing Android when it comes to Java.
There's nothing wrong with Java. You can get by in Android just fine without doing anything special, using 3rd party libraries or whatnot. But "get by" is the key word there. At some point, as you're building a UI and have to implement your umpteenth onClickListener, complete with pre-generated boilerplate code for the override, you'll sit back and wonder if there's a better way.
And that's what people have found. There's better ways. Not all of them are right for what you want to accomplish, but for me, anything that makes my job easier and less tedious is something worth looking into.
You have to use Android Studio. The UI is created using XML (or through pure Java code)
I don't believe there is such thing as Android Java.
There are however libraries made specifically for Android, for example Realm. You also have to learn some Android specific stuff such as not performing networking on the main thread.
Flow kinda sucks though due to its additional complexity such as "the backstack doesn't exist before after onCreate()" so I prefer the other options like the lib I wrote to replace Flow (as mentioned here) , or Conductor.
Not Magellan because any navigation library that doesn't handle at least in its samples how to persist and restore state are not to be trusted.
The subscoping of Mortar's dagger modules and them injecting Observable<Data> directly is super awesome though. I haven't seen that done anywhere else. So this is still interesting and oddly revolutionary considering how people still use multiple activities for whatever reason.
Don't past the data in MyRecyclerAdapter constructor. Add public method setData() to adapter. Remember to call notifyDataSetChanged() in it after setting data:
public void setData(RealmResults<MyPojoType> results){
this.results = results;
notifyDataSetChanged();
}
to query data use findAllSortedAsync instead of findAllSorted.
https://realm.io/docs/java/latest/#asynchronous-queries
Right now you are blocking main tread.
Actually the ARM binary is only about 700 kB. You only get 3 MB if you bundle all architectures in the same APK. Granted, Split APK doesn't work well yet for how we distribute Realm so right now it is a bit of a pain to create separate APK's. We have a work-around described here: https://realm.io/news/reducing-apk-size-native-libraries/ .By the looks of it though, once Google release 1.4 of their Gradle tools we will be able to make Split-APK work like it is supposed to, which will help a lot on the size issue.
Yes, Its not a large dataset. But if you are planning to scale in future, you can use sqlite transactions. Keep this in your mind sqlite doesn't support multiple write at a time. But you can manage multiple write with locks. If you want a simple solutions try realm (https://realm.io/products/realm-database).
You can also just implement this RealmModel interface instead: https://realm.io/docs/java/latest/#realmmodel-interface and with Kotlin extension functions, you can achieve the same behaviour: https://github.com/realm/realm-java/pull/4684/files#diff-011563566be082173e3fb25238919a06R10
> Struggling with Cursors and Sqlite integration
I highly suggest you check out Realm. No need to write SQL and no need to create cursors.
Edit: link as per u/Zhuinden suggestion
As far as I'm aware, Realm live objects do not work very well with RxJava that assumes you will be using immutable thread‑safe objects and that's the reason why unfortunately many people have to end up using copyFromRealm().
> RealmObjects and RealmResults are also live objects, which means that they are continuously updated with the latest data from Realm. This is great for consistency, but doesn’t work well with RxJava’s model that favour immutable thread‑safe objects. Therefore, we have added Realm.copyFromRealm() which makes it possible to copy Realm data into normal Java objects, effectively detaching them from Realm. This has a cost in terms of both speed and memory usage but can make it easier to work with operators such as buffer().
Taken from here: https://realm.io/news/realm-java-0.87.0/
I still don't fully understand why when you do a Realm query an you then transform the result to an Observable with asObservable() the emitted values are still Realm live objects. To me, it looks like it should emit immutable data models because the Observable is already in charge of providing the reactivity.
Well based on this news post, I'd assume the Java backend would have to communicate via the "Integrations / Data Connectors" port on the right.
Performance looks quite real-time to me, which is really cool!
If there's something that's a "devil in the details", it's the conflict resolution rule. I know nothing about it yet.
But I'm hyped :D With Realm 2.0 adding Object Store integration, I'd assume the platforms will have more interoperability, which is why the Realm Object Server can communicate the changes directly to its managed Realms.
Personally I use Realm (https://realm.io/), it's a much better alternative to Core Data. Many times faster at reading/writing, a hundred times easier to implement and setting up listeners that react to changes in the database such as what you're asking is very simple. They have libraries for Obj-c, Swift, Android, React Native and Xamarin.
If you're dealing with data from a server I'd have one class that deals with the networking and writing to the phone which can be accessed through a singleton (I know a lot of people don't like singletons, this is pretty much the only time I think they're a good idea), rather than pulling data in every viewWillAppear, that way you only have one reference point that you need to keep track of.
Hope that helps!
Xcode is just IDE but it supports Core Data http://www.raywenderlich.com/934/core-data-tutorial-for-ios-getting-started, because it is apple's framework for storing data.
Lately I have been using Realm https://realm.io/docs/swift/latest/ and to be honest I find it faster and simpler. There is less to do to make it work. In the URL that I gave you , you will find everything that you need to start.
I'd offer another vote to check out Realm. I've been using it lately, and the dev shop I am at has been using it in a few recent projects and it has been pretty slick.
Ok wow, I remember running into gross situations from working Realm, but I didn’t haaate it.
But! It looks like part of my issues were resolved!
https://realm.io/blog/obj-c-swift-2-2-thread-safe-reference-sort-properties-relationships/
I still vote Firebase though, especially if you don’t have a ton of complexity. Auth + crashlytics + easy integration into the google apis makes it a pretty clean solution!
I love Vue but...
Your comparing a project with 120 contributors to one with almost 2k. The amount of and quality of third part packages alone is going to be a deciding factor at that point. Most major native mobile app packages like realm have direct support for react native.
>We tried react native years ago and it was a painful experience. Recently we played around with nativescript using vue
Well that is a ridiculous comparison. Two years is forever in "javascript mobile app solution" terms. Nativescript barely even existed then.
>I mean after vue 3.0 I suspect whatever gap that exists will greatly diminish.
Not really because the gap is not really a framework specific thing. Its a community thing. Vue just needs more time to catch up in that area.
I don't think MongoDB would work because it's not embedded on device and isn't nearly as portable as SQLite. Something like Realm (https://realm.io/products/realm-database) would be a more appropriate NoSQL alternative. However, SQLite has a JSON extension (https://www.sqlite.org/json1.html) that would essentially provide a similar service. In my experience, most people usually have a schema to their data, even when using a NoSQL database... they just prefer to store JSON blobs over tabular data.
> I plan to have a way for users to log-in with a password so if something happens to their phone they don't lose their information.
That means the data is stored on a server and its own database (think PostgreSQL or MongoDB), and not just on the device.
> but I am wondering if the information for SQLite is stored locally on phones?
Yes
> Are Relational Databases still popular?
Probably, depends on the use case
> What is your favorite?
Not sure, it's easiest for me to just list that there is
SQLite, SQLite has a bunch of wrappers called ORMs like the official one made for android called Room which is therefore pretty standard and most likely recommended, (there is also Requery that I heard good things about), there is SQLBrite+SQLDelight which help in a weird way
Realm, a NoSQL DB, which was popular 2-3 years ago but you don't really hear about them lately for some reason, it has its quirks but I have a wrapper for it which should make it reasonably easy to use with latest recommendations, just like Room - built-in support for <code>LiveData&lt;PagedList&lt;T&gt;&gt;</code> for example
ObjectBox, which is also out there and I'm sure some people use it
Good article.
I used Core Data in my first significant app back a few years ago. This was before Apple updated the APIs with things like NSPersistentContainer. It was pretty rough. I definitely spent vastly more time learning and debugging CoreData than any other part of my app. Looking back through the lens of this article, I was definitely breaking a bunch of these laws which definitely increased my app's complexity.
These days I mostly just use Realm, but I really should give CoreData another look.
Well if you can run a Realm Object Server on some Linux or Mac somewhere, then Synchronized Realms of the developer-edition Realm Mobile Platform give you this out of the box for free.
https://realm.io/products/realm-mobile-platform/
The way it works is that the user is authenticated by a username that has the format of an email address (and his password), and then synchronization is automatic. Transactions are cached if done offline, too. There's some weird merging mechanism in the background which says "deleted objects stay deleted, otherwise merge all stuff". It's in the docs.
This whole "lack of null support" fiasco is hilarious to me because I remember the "good old times" before Realm 0.83.0 when there was a lot of pain involved regarding supporting null fields and having to map over to "" for Strings and stuff like that - then Realm went and added null support in 0.83.0 as it is <em>expected</em> to work .
I'm honestly surprised that some people afterwards arbitrarily decide that "yup, we've seen how much people hate not being able to use null as a value, so we're going to disallow it anyways".
Sure, it might be in the Reactive Stream Spec, but maybe the spec sucks and needs an 1.1?
We're in a really awkward time in history on this front. We've got easy to use cloud stores, but we need to provide instant offline writes for a decent experience (allowing multiple clients to write causing potential conflicts etc.). The theory is there, CRDTs fit most circumstances enough to be the new default, but the libraries aren't there yet.
You're about 2 years too early for this to be a solved problem. A better equivalent to Realm's new platform will be a free commodity in a couple of years, the backing stores will be replaceable as well, the server can be as dumb as rocks. Realm's implementation is there feature wise, but they've taken a strange approach.
Anyway, the "right" way is a chunk of effort your first time:
- Write your changes to a log (think database journal, not plain text logging) in a neutral format (JSON or a better binary format)
- Take this log and apply the changes to your "derived store"
- Replicate this log to CloudKit (a simpler/generic/conflict free problem)
Use some combination of CRDT based techniques to avoid/handle conflicts. CK becomes a dumb file store for "log" files. Your CK model doesn't change between aps.
Effort to get setup, but you can reuse 80-90% of your sync code between apps.
Ironically enough, there is an awesome talk from a former UIKit engineer over slimming down controllers hosted on Realm, perhaps it may be of use? https://realm.io/news/andy-matuschak-refactor-mega-controller/
You sure can! What you can't do is to override your property setter & getter methods, since Realm will replace them with its own optimized database accessors. See https://realm.io/docs/objc/latest/#realm-object-setters--getters-cannot-be-overriden
here's a presentation I saw on it once :). https://realm.io/news/oredev-ty-smith-building-android-sdks-fabric/
It's a less common thing so resources may be a bit scarce. You'll need to make a library project. and once you have something shippable distribute it on bintray or something.
According to their website:
"Realm Inc. already generates revenue by selling additional enterprise products & services around the technology. If you need any features not available in the public releases, need additional tooling around Realm, or services to help your enterprise apps get going with Realm, we’re always happy to chat at ."
RxJava is a library that allows you to use Functional Reactive Programming paradigm instead of Imperative paradigm. To be honest, I personally don't trust it, but many other people do. I've distrusted things I shouldn't have distrusted, and I've trusted things I shouldn't have trusted before.
Kotlin is a language built on the JVM. It has some additional features on top of Java and it's easier to do functional things in it. There's this talk about it.
Dagger is a dependency injection system. Please check out this article to see what Dagger attempts to help with, while also Dagger2 still using APT in place of reflection. Which essentially means it generates code at compile time, instead of hacking it together in runtime. Dagger2 might seem intimidating at first, but I think all you need is a tutorial on setting it up.
You can set up your ViewModels to be unit-testable. The BaseObservable class comes from the data-binding library and is not part of the Android runtime. The annotations are all processed at compile-time.
This is important to note - the data binding library does all its magic at compile time. It generates code. There is no runtime reflection or any of that. This is why the library is backward compatible - you can use data binding all the way back to .. I don't know .. API 10?
When you add the 'apply plugin: "com.android.databinding"' line in your build.gradle, you are actually adding a dependency to the library that includes classes like BaseObservable etc; and you are adding gradle tasks that hook into the Android build process to compile your XML files containing data binding expressions into plain old Android XML file (remember, the Android runtime does not understand the data binding expressions).
So, yes - the BR class, the YourActivityBinding class, the ObservableXYZ classes - are all available to unit tests.
In RC1 of the data binding library, they added two-way data binding. I am still exploring how to make use of this while maintaining unit testability. From the looks of it, I imagine that I would keep the event handling code in a separate class - that is also what the example shows. That way, your ViewModels can be tested locally on the JVM while you can choose how you want to test the other direction (event handling).
I highly recommend this talk by the developers behind the data binding library.
Boom, Thunder across the sky Thou summoned me m'lord!
Realm dev here. Realm is as stated a NoSQL database, or more accurately an Object Store. The advantage is that you don't suffer from loading foreign collections all the time (which happens in all ORMs) but can access you data though normal object references without problems. Disadvantage is of course it isn't SQL, so we have our own query language. It is relatively type-safe though and should be easy to pick up. Also we have a zero-copy approach, which means that everything is lazy-loaded incl. query results. Currently we are 200-500% faster than SQLite on almost everything (except bulk insert).
Realm objects are immutable outside a write transaction, but our model classes must have both getters and setters like a normal POJO. It is a requirement we are working on lifting though so you can have any/or no methods in your class and it would still work.
Realm objects are currently what is called thread confined which means that they cannot leave the thread they where created on. The reason for this is consistency as that is only way to ensure that your "object graph" is consistent, but we are painfully aware that this approach causes problems with quite a few Android frameworks and libraries, so it is something we are also looking into providing solutions for.
If you have a use case where you need to expose data as Cursors, Realm is probably not for you yet as Cursors are still on the roadmap, but our documentation has quite a lot of examples here: https://realm.io/docs/java/latest/ and I recently made a talk about how we are building Realm which could also provide some insight: http://www.slideshare.net/ChristianMelchior/realm-building-a-mobile-database
I would recommend a nanodegree from Udacity
It costs some money, but the courses are designed by Google in conjunction with Udacity and the certificate is signed by Google as well.
The nanodegree will give you a portfolio ready projects and also help you build up your resume and linkedin profile to get you prepared for the job market.
Overall, I feel that the Udacity nanodegree will give you a leg up on getting into the field.
On the subject of building a password manager look at encrypting the database itself, there are a few databases that you could use on android that could be encrypted. One would be realm.io which would encrypt the entire database itself.
I suggest using Realm. While it has some limitations (mainly the fact that you can't pass its objects between threads), the API is very simple. All you need to update the object in DB is calling student.setName within Realm transaction.
I've been researching for a while about this. The closest thing I've found is MongoDB Realm. As you will see in the docs it does not support Flutter yet. One MongoDB official forum "indicated" that a Flutter driver is in active development. I also wish to know if there is a better solution specifically to store data locally.
If you want to sync your data between several devices / operating system at Apple ecosystem- use Core Data + Cloud Kit.
If you store your data only at single device and synchronization is not required- use Realm.
It’s more faster and convenient rather than any other database available for iOS:
Check out the documentation for opening Realms. You'll find that you can open a specific Realm file by setting a property on the RealmConfiguration object passed into (Realm(configuration:)).
You can absolutely put more than one object into a Realm. All you have to do is create multiple classes that subclass Object and add instances of that subclass to the Realm by calling add(:) on a Realm instance (inside of a write block).
For your final question, you should not keep a Realm for every month. It would be an inefficient use of realm, and it would be very difficult to reason about, manage, and query. Instead, you should have a single Realm that has a model with a property that identifies a user; a property that identifies the month (and probably year); and a property that identifies the activity log.
It seems like Realm is also an option now: https://realm.io/blog/realm-scales-to-the-web/
Realm is pretty awesome for mobile apps, so if they can transfer any of that magic to GraphQL it would definitely be something to look out for.
Use realm only. Its very fast than all alternatives.
I have used it in Futuro SMS.
Checkout the app/db folder in the repo to understand.
For more info, checkout https://realm.io/docs/javascript/latest/
And CoreData has relations. Sometimes it's easier to use a wrapper like SugarRecord.
I think you should go for it the other way around and tell sqlite to open the file you downloaded in the Documents folder. It does not look like react-native-fs let's you choose where to save files, that might be because of the sandboxing done by iOs to control what your app can and cannot do.
If your only objective is to store data locally, I highly recommend Realm. It is way faster and easier to use than SQLite IMO, but I never generated sqlite files on my server, so that my not fit your usecase. My approach is that I get the data I need from my API in JSON and save it with Realm.
> a store is for keeping your models in a centralized location where they can be updated and observed upon.
Funny, that sounds exactly like Realm. I mean, have you read the docs?
> Persistance across process death is overblown in most cases.
Any app that dies when I switch away to Skype or Chrome and forgets my progress is a shitty app.
> in that case your app will likely crash when your user returns back to it and there isn't much you can do about it.
Yes you can, onCreate(Bundle) and onSaveInstanceState(Bundle) were designed for handling this scenario.
> However that's a severe edge case that should almost never happen.
Except when you open a notification in Skype (then expect to go back to your app), or share screenshot through whatever chat platform you use, etc
> Mind if I ask you about the "injection" part you refer to
You should only ever have one instance of UserDb in your application. You can use a DI framework like Dagger 2 to manage the scoping of your dependencies. Check out Dan Lew's talk on dependency injection made simple
> I still can't see how I can be notified about the result of the operation (in this case a change in the database) on my activity if it isn't subscribed when the signal is emitted.
Imagine UserDb has one method Observable<User> observeLoggedInUser(). An Observable<User> doesn't represent a user, but a stream of User instances over time.
When you first subscribe to this observable, it will emit the current value of the user in the database. This should be a hot observable, meaning it will emit every time the logged in user is changed in the database. You would start observing the User in onStart() of your activity, maybe. And unsubscribe in onStop.
You may also want to represent the User as an algebraic data type, so you could separately handle a logged in user vs no user logged in. Self-plug - check out my article on API design return values. Ex:
abstract class User; //would be a sealed class in kotlin class LoggedIn extends User; class NoOneLoggedIn extends User;
Now you can easily observe either type of user!
Observable<UserLoggedIn> observeLoggedInUser = userDb.observe() .filter{ user-> user instanceOf User.LoggedIn } .map{ user -> (User.LoggedIn) user };
> Is the event bus the same as RxJava?
EventBuses were cool back in the day, but RxJava has completely replaced them. RxJava lets you define threading, compose multiple events and merge them into one, etc. Very powerful.
I recorded the network traffic of the official Nightly News App to get the URL that provides the latest video. This should be possible in other apps as well depending on what shows you need.
You can use Charles on your computer to get a lot of interesting URLs from apps on your phone (or computer), which is by the way the method Workflow uses themselves as you can see in this talk: https://realm.io/news/conrad-kramer-reverse-engineering-ios-apps-lyft/
I'm happy trying to help, if you need anything specific.
How about this. Realm has not which can negate a condition.
It also has in which can find all the objects whose field contains a value within an array: > public RealmQuery<E> in(String fieldName, Integer[] values)
So, if you simply had a list of all the currently valid id's, you could query the Realm for objects whose values were 'not' 'in' those.
You can do this by running a regex on the json you receive, to pull out all the id values.
Then construct the realm not in, and simply deleteAllFromRealm.
I think that'll do it right quick.
> I think I'd rather just learn a crappy way than waste time not learning anything at all.
Eh, until you copy a proper architecture that separates <code>data/domain/presentation</code> to their own packages (or modules if you're extreme) and enforces an MVP design where the Presenter is completely independent from the View (Activity, ~~Fragment~~ Custom Viewgroups, Adapter) and contains all state that is required to set up the view after restoring its state; most techniques will be bad techniques.
Single Responsibility Principle and Dependency Inversion Principle are your primary two friends.
Time to read:
This argument has been going on for a while. I've heard various arguments for WebApps but never bought into them. It's nice to have one code base that runs anywhere, but it does come with it's costs.
I've just started watching a series on the costs of java. Java is different from ObjC/Swift in that it's not actually compiled.
https://realm.io/news/360andev-jake-wharton-java-hidden-costs-android/
Even now, years after mobile started, Android doesn't seem to have a common compiled language. Given that there is a limit to the power that can be put into the chips on a mobile device, having a bloated runtime or VM system doesn't seem to have a great future to it.
All web apps seem to offer is a common code base. This can be helpful, but it'll have it's own set of limits.
I hope I never have to do webapps, I don't even like VM languages like Java, I'd rather go TRUE compiled. Speed and power allows you to do more things for your users.
https://news.ycombinator.com/item?id=12591165 explains this in a bit more details. The bottom line for most developers is that the system has 100% guarantee of consistency with fully automatic conflict resolution. And if you have a need to do validation or custom merging, that's also possible at the model level using ordered lists. See details here: https://realm.io/docs/realm-object-server/#conflict-resolution
You create your SomethingInteractor inside your Context-aware object (Activity/Fragment/ViewGroup), and you pass it into the presenter. For example, using the code of this project, instead of:
DaggerFactory.getMainComponent(getPokemonApp(), this).inject(this);
which will do all that Dagger magic, one can simply do:
Context context = getActivity().getContext();
presenter = new MainPresenterImpl(this, new SomethingInteractor(context));
Dagger is not a silver bullet: all it does is automate what you would otherwise need to write by hand. Don't believe me? Check out this amazing talk by piwai who does a step-by-step explanation of how to go from manual to Dagger (Seriously, watch it, your life will be changed forever)
<rant>You don't need to use a DI framework to do DI. You can do it with constructors, with setters, or with factories. Dagger is just a very smart factory of factories. The tool (in this case, a library) shouldn't restrict its user (the developer).
I would argue that, for this example project, one doesn't even need to use Dagger. On one hand, you get a ridiculous amount of configurability in your project (for each @Provides added, the possible configurations is multiplied by the number of possible different implementations of the dependency). On the other hand, here are the disadvantages:
- 300+ lines of (cryptic) code, as opposed to a bunch of constructors. Just because it comes with an annotation, doesn't mean its meaning is as clear as a construct that is taught in Java 101.
- Having to add an external library. (Yes, my friends call me the minimalist developer)
- The number of bugs that are created with every single extra line of code
- Do you even need that much configurability? Shouldn't spend that energy writing tests instead? </rant>
OP: this rant is not a criticism of your project.
Maybe, but the documentation specifically says that it increments a reference counter that it decrements when you call <code>close()</code>. it's even mentioned in the best practices section which I would think is somewhat essential.
Realm: - requires your model objects to extend from <code>RealmObject</code> - makes you jump through hoops to create instances of models - automatically refreshes your model instances, which can be a great feature but should be used with great care
This list is far from exhaustive as I have not worked with Realm that much.
Good thing to know is I'm fetching data from the three current platforms via a cronjob to my database. The app connects via an api setup with Laravel 5. Images are downloaded and cached via the UriImageSource from Xamarin. The app is being build with Xamarin.Forms.
I've reached the point where I want to save local settings like favorites. I'm thinking about using Realm (https://realm.io/docs/xamarin/latest/) for this.
I'm a little new with this so any tips, suggestions I should keep in mind?
Thank you :)
I have some experience with it, I've created some apps that basically store/syncs with an API. Whenever a user has no internet access the user would still be able to read whatever article is already downloaded. I used Realm for this approach. It is basically a easy way to work with databases.
If you're not using Realm for whatever reason. You can use the sqlite database. Android supports this. However this requires you to do a lot of coding OR use a 3rd library ORM (I can only name GreenDAO but there are lots). These are obviously relational databases and not NoSQL though.
Hope this helps
Oh lord, two hours. I'm gonna have to get seated for this one sometime. Although this is also really why I really like Realm's style (example), where you can just browse through the slides and read a textual version of the presentation. Although that also requires quite a time investment to create, which might not always be possible.
I have been looking for a SQLite replacement as well. All libraries out there provide nice abstractions and clean query APIs making them very tempting to switch to.
But I'm wondering if any of these libraries have efficient support for a very common case: where you have a huge number of rows in your table and you need to bind them to a list? I don't want the library to make a copy of thousands of items into a List/Collection (due to abstraction) upfront before I can bind them to UI. I'm still relying on Cursor mostly for this.
Digging into the docs, look like DBFlow supports this use case ^1, as well as Realm ^2, while I can't find a similar documentation in Requery ^3.
Core Data is very easy to use when accessed on the main thread, it gets a bit more complex when accessing it on background threads. For very short reads and writes you might be able to get away with just using on the main thread, but probably better (if you choose that route) to just bite the bullet and do it in a background thread first. There's also things like https://realm.io/ (I haven't used it).
As mentioned in another post plists are great b/c of native support.
JSON through SwiftyJSON or another library would definitely be doable as well.
I have this open in a different tab which shows why you should avoid JNI: https://realm.io/news/romain-guy-chet-haase-developing-for-android/ (search for "avoid JNI). This isn't so much about the performance of Java vs. native as much as about the overhead of leaving Java into C.
I can mostly comment on what I see in terms of speed and my experience on our own VM's both here and at Sun. I did google just now and I saw one 3rd party benchmarks putting ART at roughly 50% slower than LLVM C. So I'm guessing its not as fast as hotspot for some cases.
I did benchmark Dalvik a lot when working on our various ports. It was pretty hard for me to match Android's performance on iOS during the Dalvik days.
We also benchmarked ARC (Automatic Reference Counting) from Objective-C/SWIFT and I can tell you that it isn't a panacea. The locking required for ARC is problematic in terms of performance where compared to the GC approach.
Here's a couple of links that I used to learn about it:
Official Android Developers Data Binding guide
Hey, thanks for your feedback. We have a lot of work ahead of us but it helps to know what users care about. As far as Realm being production-ready or not, that’s up to each & everyone to make their own impression, but Realm powers thousands of apps and runs on hundreds of millions of devices already, including in apps from Google, Amazon, eBay, Homeland Security, banks, healthcare providers and many, many more (https://realm.io/users). Onto your feedback:
- We are almost ready to release a major improvement for POJOs — look for it in January.
- Sorry to hear about the ANRs, if you have any outstanding cases please let us know, otherwise be assured that stability is a top focus for us right now, and a big reason why we don’t label ourselves at 1.0 yet!
- Finally, we never aimed to support BlackBerry; people reported specific bugs and we confirmed we were able to fix them, but BlackBerry isn’t and was never a platform we officially meant to support. If you are interested in us supporting it, please open a GitHub issue https://github.com/realm/realm-java/issues so we can track community interest for it and prioritize it, and set up all the testing infrastructure around it.
Thanks again for your feedback, knowing what to improve is the only way we can make Realm better.
I've been experimenting with it and its not bad at all. Dependencies are a bit of a pain compared to other languages, especially if you end up building a binary (you have to do some framework linking). This talk from a few months ago gives a nice introduction to plain old scripting, but doesn't dive into making cli's.
Realm does support multithreading now, but there are some limitations to it. Making async requests is super easy though with their query API.
A lot of the issues you faced seem similar to mine and having to mirror RealmObjects and POJOs was a pain.
Read up on dynamic height in table views which are supported as of iOS 8.
http://www.raywenderlich.com/87975/dynamic-table-view-cell-height-ios-8-swift
Also read this:
http://stackoverflow.com/a/28048809/1888476
Are you doing a set number of rows for this table view, or is it an infinite scroller? You may also want to consider treating each "cell" as a combo of sections and rows instead. The section header could contain the collapse button and different cell types could make up the rows in the section.
Yelp had a pretty good talk at this year's Alt Conf that went over the idea and how they're using table views which is worth watching:
https://realm.io/news/altconf-mason-glidden-advanced-uitableviews-for-fun-and-profit/
1) You can't store UIImage with CoreData - instead, you should save it to file and persist filename (this is also true for most solutions which persist data)
2) I can recommend using Realm if you want to make your classes persistable (without creating CoreData models and all other fuss). All you need - to make your class descendent to Object and change tags var type to something like List<StringWrapper> (but you still need to save image to file).
Well, it lets you define a function in-place, for one. That means if you had some function that took another function as its argument, you could define the closure right where you call the higher-order function.
Closures also have a couple of different behaviours to functions. First off, Swift can infer the types of a lot of things, so you can leave out the type information:
let add = { (a, b) -> Int in return a + b } // or let add = { (a: Int, b: Int) in return a + b } // or let add = { (a, b) in return a + b }
It can also infer the return (if there's only one statement in the closure):
let add = { (a, b) in a + b }
And you can use shorthand argument names:
let add = { $0 + $1 }
The second different behaviour is how it handles references. Closures are reference, not value, types. They capture (i.e., hold a reference to) any variable that they use other than their arguments. This gets into weak, strong, and unowned, though, which is a whole nother thing. This video has a pretty good explanation.
Not sure if Apple is targeting Storyboards at any particular group, but after working with them in a few apps, it's going to be a long time before I try them again.
The only time they've been ok have been the situations in which I've basically used them as a xib.
That being said, meh, I don't care much for xibs either. I find using masonry, stackviews, and subclassing UIView when it makes sense leads to code that's easy to browse, and easy to grok.
I found myself feeling slightly vindicated hearing Andy Matuschak's remarks on Storyboards in his latest presentation.
Predicates are a bit more complex, kind of like a query. Look at http://nshipster.com/nspredicate/ for a bit of background. And https://realm.io/news/nspredicate-cheatsheet/ for some quick help. In particular look at the SELF section which explains how to do what you're after. NSPredicate* p = [NSPredicate predicateWithFormat:@"SELF == %@",@"imgur.com"];
You may also want to look at the imgur API. It's pretty easy to use when your browsing public content. You just have to add in one header with your app key and it's done.
Also the way you're doing network calls will need to be changed. Right now your app is going to be locked up until the call finishes which is a bad user experience. But that's a big topic which I'll let you look into yourself.
Christian from Realm here. I am not sure there are any tutorials that covers everything, but a good starting point would be our documentation https://realm.io/docs/java/latest/ and example projects https://github.com/realm/realm-java/tree/master/examples
If you find yourself starting projects for fun on the side, or even courses with looser constraints on technology/implementation... I'd very much suggest looking at using a wrapper or alternative DB rather than using Core Data directly. Magical Record is one such straight wrapper. I myself have been using an alternative DB called Realm. Much easier and straightforward either way.
Only the masochistic or performance anxious use Core Data directly in production. :P
Kenneth from Realm. We have published a few benchmark results when we initially released our Android binding: https://realm.io/news/realm-for-android/.
The absolute numbers will of course depend on the device, but the relative numbers are fine.
Internal benchmarking (at Realm) indicates that relative performance isn't depending on the number of rows/objects. Of course, 10000 rows/objects is a much heavier load than 100 rows/objects but the relative performance characterics (comparing SQLite and Realm) is the same; probably because both SQLite and Realm is limited by the I/O subsystem.
Check out this talk. https://realm.io/news/swift-summit-daniel-steinberg-functional-programming-for-everyone/
Daniel is very active in the Apple dev community and I'm sure he'd be happy to give you some tips. The playground he uses here might be up on his github repo.
Look at this too. http://swifteducation.github.io
If you need to store more than just a bit of data, use CoreData or Realm, it's more effort to set up, but works nicely and has many features.
Also by user I think you're refering to the user's icloud account? If so, you can set up a CoreData store in the private icloud, which will be specific to that user, see here for more information.
If you're having trouble getting started with CoreData I could give you a simple sample project. (I don't have any experience with Realm and I don't know whether it's possible to use iCloud with it, but I heard lots of good things about Realm, it's easier and swiftier)
Oh and: NSUserDefaults is good for settings, use CoreData or Realm for user data.
[Edit for premature posting. Dammit Alien Blue!]
CoreData is handy when you have a bunch of inter-related objects and don't want to mess with all the book-keeping and relationship management.
The other place it comes handy is how it's deeply linked into collections and tableviews.
But to get it up and running is not for the faint-of-heart. And you have to be careful with multiple threads and blocks.
Unless you're using this as an excuse to learn more about CoreData, suggest you consider alternatives. Your model looks pretty simple. Might want to take a look at https://realm.io or one of those libraries that wraps SQLite inside an object-relation mapper.
Another vote for Realm, it's amazing compared to everything else I've seen.
https://realm.io/docs/swift/0.92.1/
Here's a quick and dirty view as to what it might look like:
class Location: Object { dynamic var lat = 0.0 dynamic var lon = 0.0 dynamic var alt = 0.0 }
class LocationSaver { let realm = Realm()
func saveLatestLocation(lat:Double, lon:Double, alt:Double) { var location = Location() location.lat = lat location.lon = lon location.alt = alt realm.write { realm.add(location) } }
I used Sugar ORM and ActiveAndroid.
ActiveAndroid is my go to, and looking right now it has similar syntax to DBFlow.
I like more Queries from ActiveAndroid, SQL commands are like functions inside library so queries in ActiveAndroid looks like: > return new Select().from(Item.class).orderBy("RANDOM()").executeSingle();
While for DBFlow you will have to write SQL statement like string: >query = "SELECT * FROM TestModel2 WHERE model_order > 5"
Anyway, they are fastest ORM, and the analysis on DBFlow site is for 25,000 records to the database (which is super rare for mobile app). If you really really want speed then you would go for RAW SQLite, or Realm (they said they are 7 times faster than raw sql)
You can use whatever database you want. There's no "best" database for SwiftUI, or any project tbh.
The most "compatible" database with SwiftUI is CoreData since there are property wrappers like `@FetchRequest` which is very useful.
If you want to use MongoDB, I'd recommend Realm since it's a mobile friendly database.
But all in all, if you already use firestore and have a working setup, there's no need to mess around. Just do what you always do!
call the duplicated data "index" and be happy. Double linked list exist for a reason. I think realm.io and neo4j keep duplicated data under the cover.
SQL Gurus would CREATE a n:m relation table. Then people come up with hyper mathematical stuff how to store that.
I ended up using the Realm Database.
Realm lets register a notification handler on a specific collection. The handler receives a description of changes since the last notification. Specifically, this description consists of three lists of indices:
- The indices of the objects that were deleted.
- The indices of the objects that were inserted.
- The indices of the objects that were modified.
Another plus point of Realm over SQLite is that these change notifications are NOT limited to changes from the same connection.
From an API point if view, a possible solution (depending on your architecture) is using https://realm.io with their sync feature. Or you can https://hasura.io with their real-time graphql subscriptions.
From the docs
>Results is an auto-updating container type in Realm returned from object queries.
In simpler terms you can use it like a list, but it will update when the result of the query changes, e.g. in psuedocode
let result = realm.fetchAllObjects() print(result.count) // 0
realm.insertNewObject() print(result.count) // 1
I'm on node version 14 as "node -v" on the console informs me. The way only way I could install realm on the project was using "npm install --save ". I tried using "npm install --save realm" like the tutorial on realm.io but no luck.
Hello.
Using the approach described in https://realm.io/docs/kotlin/latest/ to store enums in a Realm Model class.
I have a Item class with a ItemType (enum). I'm having trouble querying for items that match a give ItemType.
realm .where(ItemRealm::class.java) .equalTo(ItemRealm.ITEM_TYPE, "OFFICE_MATERIAL") .findAll()
I get the following error: Invalid query: field 'itemType' in class 'ItemRealm' is of invalid type 'OBJECT'.
Any suggestion?
I dropped Realm at the start of this year, too. One of the main reasons for me was that it is such a massive 3rd party dependency, which meant, among other things, that it increased build times and on older devices (i.e. 6S and 7) increased the app's launch time by ~35ms on average, which is almost 10% of Apple's recommended 400ms.
Another thing I found was that there were a lot of bugs, many of which had already been reported ages ago. It was frustrating having so many crashes that were "out of my control".
Anyway, in case it helps anyone in the future, there's a simpler way to access a Realm object from a different thread called ThreadSafeReference.
I have been looking for code for a few hours, I was looking for code, not for “about information”. Give your understanding of English an honest evaluation before trying to use it in a response.
This is what code documentation looks like
At Realm, we tackle some of the same problems, being a core database component written in C++, with several mobile platform bindings for iOS (Cocoa, Swift), Android (Java, Kotlin), ReactNative (JavaScript, TypeScript), Xamarin (C#), and then Node.js for certain server-side components.
I'm not going to lie, it is sometimes a challenge. However, we're in a situation where the C++ components are mostly reliant on the particulars of the operating system, and not things like UI interaction or peripherals. This means that, in practice, the C++ components only really need to care about a couple of platforms, namely POSIX (more or less) and UWP.
That's hard enough as it is, since the POSIX-compliance on Android and iOS is... divergent, let's say. But the main challenges are in setting up a reliable CI process.
I strongly believe that instead of sharing code, a project which aims both platforms does benefit from sharing coding philosophy, techniques and cross-platform libraries .
For example, for my iOS/Andoid projects i usually use same libraries for doing the same on each platform whenever it's possible (for example, i useRealm.io when the project requires a db layer, RxSwift/RxJava for reactive libraries, etc.) , and try to follow the same coding principles (MVVM as architecture, etc.)
This helps to make that both projects feel almost like a single one, making it easier to understand, maintain and add changes.
According to this,you only need to pay them if you're going to use their cloud databases. Regarding cloud databases, if you're going to store the data locally, there's no need to use a cloud database. (For a "serverless" approach however, cloud databases may make sense. For example, a lot of apps use Firebase)
Looks neat! I think the people over at Realm could probably appreciate it as well- almost as fan art :D! Not saying yours isn't its own thing! Just mentioning it could be almost be a redesign of their logo.
In Realm 5.9.1, what is the alternative of <code>createObject</code>(<code>Class</code><E> clazz, <code>Object</code> primaryKeyValue) which would replace existing item like createOrUpdate.
It's not a big deal to master platform. What is a big deal is to maintain solution which is not intended to work offline. Like installing Oracle to have a local database. Just don't do that! You can use Realm for UWP https://realm.io/docs/dotnet/latest. Or SQLite PCL https://github.com/praeclarum/sqlite-net.
URLSession should by default cache the response for some configured time so if you make the call again within the allotted cached time, it will read from cache. However, if I were to implement this feature I would use some sort of persistence layer to allow for a better user experience. I generally follow the MVVM pattern and use Realm as my persistence layer with RxSwift to achieve data binding. This way, you can read directly from the DB without having to wait for a network call each time to populate the table/detail page. Let me know if that helps at all! Good luck!
I can see executeTransactionAsync() in 0.87.5 in the documentation but it isn't available in the API docs. What are the options to run Async in 0.87.5?
https://realm.io/docs/java/0.87.5/#asynchronous-transactions https://realm.io/docs/java/0.87.5/api/
>This repository contains all Realm.io related features of the MPAndroidChart library based on Realm v4.2.0 release.
Would MPAndroidChart-Realm work with Realm 87.5?
Thanks, that helped a lot.
​
The problem is that I still can not get any data from Realm. I have created POJO class and extended RealmObject and added Required annotations.
The url of Realm is something like this: realms://instance_url/TEST and inside Test Realm I have table called MyHeaders.
I get always 0 results when I do:
​
realm.where(MyHeaders.class).findAllAsync()
​
I see this error on Realm Studio logs:
​
HTTP response: 48584485-0101-4999-94c2-9992b5b7f58e {"type":"https://realm.io/docs/object-server/problems/access-denied","title":"The path is invalid or current user has no access.","status":403,"code":614}
​
You can read and write data with realm for react-native. So technically nothing is stopping you from manually making a call to a server to fetch data, then writing that data to the app's local realm database.
You can also let a user do something in your app, make some data from that, write that to realm and also post that up to a server. It can all be done with no hacking at all.
Example from realm right in this link https://realm.io/docs/javascript/latest/
There are many ways to persist data, and you have mentioned some. Core Data can be confusing, especially when you're at a beginner level. Have you followed Core Data step-by-step tutorials? For this simple project, most of it would be boilerplate. UserDefaults is simpler but typically used for storing simple items (feature toggles, basic settings).
Could check out Realm, which is like Core Data but simpler. https://realm.io/docs/tutorials/realmtasks/
There are so many tutorials out there...just follow a step-by-step tutorial. Just start doing it. Ask questions once you get stuck at a specific part of the process.
A former colleague of mine started their business by building custom Wordpress sites for their clients. After a while React and single page web applications became a thing and they had to switch to that using the Wordpress REST API.
I don't know much about the Wordpress REST API but if the client using a relatively new version of WP that REST API should be available.
I would recommend you to go that route and look into CoreData like /u/KarlJay001 said or Realm to persist your data while the iOS app is offline.
Also you didn't state what premium features they want, if they want to stream video or audio, if they want to display data in a map for example. All of these features will increase the time to develop the app significantly.
So remember to get a technical specification of what is required to deliver the product, and take wage by the hour.
Good luck OP!
https://realm.io/blog/introducing-realm
Obviously they chose benchmarks to make Realm look good, but Core Data has always been slower than SQLite. This compares Core Data and Realm: https://cocoacasts.com/core-data-or-realm/