Landratte – Deine zuverlässige Wetter-App für Landgänge

Ob an der Küste, im Binnenland oder einfach unterwegs – mit „Landratte“ hast du das Wetter immer im Blick. Die App liefert dir aktuelle und präzise Wetterkarten direkt vom Deutschen Wetterdienst (DWD) – ganz ohne Schnickschnack, aber mit allen wichtigen Informationen.



Warum Landratte?

  • Direkter Zugriff auf DWD-Wetterkarten: Alle Daten stammen aus seriösen, offiziellen Quellen (Open Data des DWD) – für maximale Verlässlichkeit.
  • Intuitive Bedienung: Wetterkarten und Prognosen mit nur einem Fingertipp – schnell, einfach und übersichtlich.
  • Klarer Fokus auf das Wesentliche: Keine ablenkenden Texte oder Werbung – du siehst, was wirklich wichtig ist, Karten, Animationen und aktuelle
  • Wetterfilme.

  • Vielseitige Prognosen: Wetter und Temperaturen für Deutschland und Europa – aktuell und für den nächsten Tag.
  • Umfangreiche Zusatzfunktionen: Niederschlags- und Satellitenradar, Luftdruckkarten, UV-Index sowie Live-Wetterkameras aus ganz Deutschland.
  • Maximale Flexibilität: Karten beliebig zoomen und im bildschirmfüllenden Modus genießen – optimiert für iPhone & iPad.
  • Kostenlos und ohne versteckte Gebühren: Alle Karten und Funktionen sind frei zugänglich – keine In-App-Käufe, keine Abos.
  • Einfach & schnell teilen: Alle Karten können ausgedruckt oder mit einem Fingertippen geteilt werden.
  • Hinweis:

    Landratte liefert Wetterinformationen ausschließlich in Form von Karten, Animationen und Bildern – für alle, die auf fundierte Visualisierungen statt endlose Texte setzen.

    Fazit:

    Mit „Landratte“ bekommst du zuverlässige, aktuelle Wetterdaten – klar, direkt und professionell aufbereitet. Perfekt für alle, die Wert auf Qualität und Übersicht legen!

    Why do I blog this? Ich habe diese App kürzlich überarbeitet, sie hat viele neue Inhalte und Funktionen. Weiter Informationen dazu gibt es auf auf der Webseite zur App. Die App heisst übrigens so, weil sie ein Kontrapunkt zu meiner Seewetter Pro App ist, die ausschließlich für Seefahrer konzipiert wurde.

Rest in Peace Twitter, jetzt aber wirklich…

Seit dieser Woche hat Twitter, die Plattform die sich einstmals als Microblogging-Dienst sah, die Möglichkeiten abgeschafft, dass Drittanbieter z.B. mit Apps wie Tweetbot mit dem Dienst interagieren dürfen. Der API Zugriff für Apps wurde einfach gesperrt. Ich denke nahezu jeder der Twitter mal nutzte, tat dies überwiegend mit dem Smartphone, also mit einer App eines Drittanbieters. Denn im Vergleich, bot die eigene App von Twitter oft die deutlich schlechtere User Experience.

Ich nutze Twitter schon lang nicht mehr, aber es ist dennoch ein dickes Ding zusehen zu müssen, wie die Drittanbieter bzw. deren Entwickler vor vollendete Tatsachen gestellt werden und ihnen MATRIX-Movie-gleich der Stecker gezogen wird. Keine einzige Big Tech Company sollte sich wundern, warum ihnen kein einziger Entwickler vertraut. Egal ob Google, oder Apple, oder Twitter oder Facebook oder Amazon… diese Art des Vorgehens kommt einer öffentlichen Hinrichtung gleich wie damals im wilden Westen Verbrecher am nächsten Baum aufgehangen wurden.

Die baumelnden Leichen (Tweetbot, Twitterific, etc.) zeigen der aktuellen Generation von Entwicklern, auf was sie sich einlassen, wenn sie mit den Big Techs Geschäfte machen wollen. Die jetzt wertlosen Apps zeigen wunderschön, wer hier mächtig ist und wer ohnmächtig zuschauen muss. Ich hoffe die Entwickler die sich oft und gerne auf Konferenzen hinstellen und von INDIE Development fabulieren, lernen ebenfalls ihre Lektion aus dieser Geschichte.

Why do I blog this? Für mich ist bereits vor Jahren klar geworden auf welcher Sprengfalle man sitzt, sofern man sich als Entwickler in die Abhängigkeit von Big Tech Firmen begibt. Es ist eine beispielhafte Demonstration der Macht, die Twitter hier ausführt. Aus meiner Sicht ist damit Twitters Zukunft weitgehend besiegelt. Kein Drittentwickler wird Twitter nochmal anfassen und ihre eigene App wurde ja aus guten Gründen von vielen Nutzern des Dienstes gemieden. Daher: Rest in peace, Twitter. Jetzt auch aus Entwicklersicht!

RealmExplorer – a piece of sample code for Realm DB

realmexplorer_01_smallFirst things first, look at the RealmExplorer github repo for the project.

Preface: CoreData

I have some history in using databases. From using Oracle, Frontbase, mySQL, PostgreSQL, sqlite etc. the last time I used a database was for a postcard app using CoreData. But I found CoreData to be a lot of overhead and boilerplate code to write.

Especially migrations are kind of not very intuitive to understand and if something goes wrong you are basically lost. While Xcode for a while had an Entity modelling tool (which had it’s roots in the WebObjects EOModeler), most of the time this tool did not work very well for me and had lots of bugs. In each Xcode version different bugs!

Also many people report running into issues when using CoreData with lots of objects, because it is easy to loose track of memory consumption with CoreData and if you do not actively check and work against that, you end up with a whole model graph being in memory. Not cool! So I wanted to try something different.

Realm

I found Realm by Realm.io to be interesting enough to tinker with. So I started working with their sample code projects. But none of those projects came even close to some real world example. So I just started prototyping something I will need for a different project anyway.

Starting with a custom viewcontroller for adding & editing entities I recognized that this would soon become rather painful to provide e.g. inputfields for text and numbers and dates. So I grabbed FXForms to give it a try after I had already completed a viewcontroller to manage DBCaptain entities a bit.

Migrations

Right from the start I wanted to know how migrations work. Because usually those are the weakest spot in every db operation taking place. With a live product you always „pray“ that nothing will go wrong during migrations on the customers device. And keeping track of changes to the db schema is very important to have a stable app.

So I built the sample around the process to „simulate“ an app in development. You can now iterate through different development steps (5 different app states & their migrations) and their needed migrations. This way I figured out how I can safely manage my migrations (i.e. always keeping a backup of the old schema). In the project the
DatabaseFactory.m class manages all that. It detects existing schemas using a precise naming scheme for each Realm-db created.

During app launch any necessary migrations are executed if necessary. Also, any errors happening while the app launches and gets into trouble activating the database, are nicely displayed.

Create/Insert/Edit/Delete

I started with one entity DBCaptain which is basically a user entity. I just wanted to create user objects and populate them with different properties. I tested insertion with one and with many users on the main thread and on the background thread. I also took advantage of notifications coming from Realm as soon as an operation finished updating the db.

Deletion of objects came next. As always having the UI keeping track of all those changes is the more difficult task. So expect some „ugly“ code, because this was only me tinkering around. When i wanted to edit existing objects I recognized that I do not want to create all those textfields manually.

FXForms

That was when FXForms came to the rescue. I started to recreate the already half done viewcontroller and created another based on FXForms. I needed some time to wrap my head around FXForms, because basically this is a quite sophisticated hack of providing compact descriptions of UITableViewCells and their content.

You describe what kind of structure your form should have and what kind of value types it should use. FXForms crafts the UITableView which makes all those inputfields come true. Things start to become a bit tricky if you want to control those UITableViewCells more directly. E.g. I needed a way to exclude certain properties of being edited at all. So I simply extended the FXForms protocol to allow for a denial of userInteractionEnabled on certain cells by adding the FXFormFieldEditable key. This is used on the CaptainFormViewController to exclude the information about the database schema and the encryption status to not be editable.

Evaluation

My first impression of Realm DB is quite positive. It is fast, it provides helpful error-messages and it is easy to setup and comprehensive in what it does and how it works. I never in my life had migrations up and running that quickly. Very, very helpful was the Mac app RealmBrowser to open a realm DB file directly. I used that while checking my migrations and the results of operations which added arbitrary data (e.g. image files).

What is actually really great is that encryption is supported for the db by just providing a 128 bit key. That is really helpful to protect user data and increase safety of the realm db file even if it gets backed up into some cloud somewhere else.

What’s next?

I think I missed something related to the KVO-thingy going on by Realm. But I had no time until now to figure that out. I suppose they actually track entities and changes via KVO. But I am not yet sure how exactly this works and how I can detect if an object has pending changes. That is why I added a hasPendingChanges BOOL-flag to both ViewControllers for editing entities. So help is welcome here!!

I did not have time to do some real hardcore performance testing, i.e. adding thousands of entities and relationships in a short time and crafting a rather complex model with complex relationships which define ownership and cascading deletions etc. Also doing sophisticated db queries is on my list to do next.

But having a prototype now to tinker with helps already a lot. Since I learn best from sample code, and I think I am not the only one learning new things this way, I hope it helps others to jumpstart with Realm, too.

Why do I blog this? I just wanted to give a bit of background info on the sample code I put on github. Have fun tinkering & I am really in need of getting more info on how I can detect changes to an object so I know WHEN to save changes to the db. Maybe someone who already grabbed the concept better can help me here?? Leave a comment or contact me via github.