I tried to find the best way to store data on a local persistant store but I did not find a lot of resources about this.
I found only :
Motion model
But what is the best gem/way to make a offline app. I mean, I sync with remote one time and after that, my application uses a local storage (cora data, sqlite...) to read data?
Thank you
I use MotionModel (heck, I wrote MotionModel) but I'm biased. It's supposed to be for use-cases where you don't want to set up the Core Data stack. That said, InfiniteRed has done a great job with RMQ so it's likely they did a great job with CDQ, which wraps Core Data.
I suggest you make a play app with each and decide for yourself.
I prefer the way HipByte suggests in the Locations sample.
Check the LocationsStore class, and how they use CoreData in a very simple way.
You could also use CouchbaseLite and leverage it's sync capabilities to make the data available offline. I created an CouchbaseLite RubyMotion Example which is a port of a TodoLite-iOS version of the App. I'm currently working on making the integration nicer and more ruby like, but it works as is.
Related
I'm working on the tile_map plugin of Mapviz. The Tile-Plugin loads images (tiles) using a WebRequest from the servers. As I have downloaded already all the images on my hard drive, I'm trying to remove the WebRequest from the code - so it wont use the network access. The plugin is using the QTNetworkAccessManager. What would be the recommended way/methods to replace the NetworkAccessManager?
Greets
QNetworkAccessManager is the recommended way (and only way that I know of that is supported by Qt) of accessing resources over HTTP. The API is made the way it is for performance reasons, it will hide implementation details, conserve power and allow for the kind of optimizations that are available in HTTP without you having to do anything special.
If you have all the files locally, I would simply wrap the code that uses QNAM so that it looks for and prefers the local copy (possibly while keeping a copy in memory too, for performance). So it would cache like this:
memory-copy > disk-copy > network-copy
TIP: I found this PDF to be really good for explaining how to use QNAM in the best way.
I'm developing a Clojure application, which downloads images from the web and analyzes them for certain criteria.
Whatever this might mean, the important part is, that there will be some quite expensive functions in the app, which take a while until they are processed.
In the end, there will be an API that exposes the app's functionality to a web frontend. This is meant to be a second step though.
Since the app has a lot to do with graphics, it makes sense to visualize the outputs of the functions I'm writing during the development process.
Basically I'm looking for an easy way / environment to archive this.
More precisely: Whenever I created a new function, I want to test it's functionality inside a browser: E.g. plot the output, draw some intermediate steps, maybe create some small interactive scripts, that help me to supervise that the algorithms are doing what I intend to. Note: I don't want to to transform the functions to ClojureScript and let them run in the browser, the browser should be just a "display".
Some approaches that came to my mind:
Writing a little backend-server that exposes all the functions of a namespace. So the front-end could access all these functions simply by sending an ajax request to the server, that includes the function and it's parameters in a string, or maybe better in edn format. The back-end receives the request, calls the requested function and sends back the result whenever the calculation is done. Is there maybe already a project, that does exactly this?
Using a project like "Gorilla Repl" This would be a good option, and maybe I'm going to use it. However, I could not yet figure out if it's mechanism covers a way to interactively influence the rendered outputs. It rather works as a worksheet with static renderings.
How would you guys do this? Any suggestions are appreciated.
I have been working on similar problems and I think that you could use the combination of Lighttable + Clojure + Nerdy-painter (plugin).
Nerdy-painter allows you to display images on Lighttable (IDE). Very useful for data exploration or anything that has to do with graphics/plots.
Disclaimer: I am the author of nerdy-painter, still I think the fastest/elegant solution is the one I described above. All other solutions add (IMHO) too much overhead to the development cycle.
A possibility is to use a Jupyter's clojure kernel to interact with clojure. Jupyter runs in a browser and you can add custom binding to simplify access to the DOM.
Here's a clojure kernel: https://github.com/roryk/clojupyter
I've been tasked with porting personal face recognition software to iOS and Mac OS X as well as helping keep the basic SDK and much of the software as cross-platform as possible. One of the things one of my associates and I want to do is store data on the user's face in an SQL database (probably SQLite). We would also like to allow users to put their data on iCloud so they don't have to train each of their devices separately to recognize them. What's bugging me is how to do both these tasks, and I'm confronted with enough choices to feel overwhelmed. (I am still new to some of the technologies involved.)
For implementing SQL, I could embed SQLite directly in my program and write code for it, or I could use Core Data and have it talk to SQLite for me. (The database is not meant to be shared, so this is OK. And SQL is not fun.) However Core Data is anything but portable (not to mention not intended for a model encoded as C++ objects), while writing directly for SQL would mean we could reuse more code on other platforms.
Things get messier when factoring in iCloud, which has something like five or six possible ways of integrating it with a program. The only method I have definitively ruled out so far is iCloud key-value storage. (At the very least, there's a good chance a user would get into trouble with the 1 MB limit, and it is clearly not intended for anything as complex as I'm dealing with.) Core Data can integrate with iCloud through UIManagedDocument or NSPersistentStore, but, again, that means less in the way of reusable code. I can use SQLite together with UIDocument or NSDocument, but what I am trying to do seems to be not quite what these objects were intended for. The files I am dealing with are essentially large preference files, not meant for end-users to interact with directly; UIDocument and NSDocument seem to be meant for user-viewable and -editable files. And then there are iCloud Drive and CloudKit, which are still in beta. (On the other hand, these two are due to be released fairly soon. Considering that iOS users tend to upgrade to the latest version of the system software quickly, arguments about using either of these based on how many devices they will be able to run on should quickly become weak and obsolete.)
Can anyone recommend which way is best suited for my purposes? Thanks in advance.
Aaron Solomon Adelman
First off, you don't want to try and share the SQLite file directly. That's extremely likely to corrupt the file, because SQLite wasn't built with that kind of use in mind.
However:
You could use SQLite for local on-device storage only and use a separate API to send data back and forth. Apple's CloudKit would probably be a good choice if you can require iOS 8+. Numerous third party solutions exist (for example, Parse). You'll have to write your own code to translate between SQLite and the network API. Your SQLite schema and your data files would be portable to other platforms, and maybe some of the code if you use SQLite's direct API instead of an Objective-C wrapper (and I highly recommend using either FMDB or PLDatabase if you use SQLite).
Core Data does have built-in support for iCloud, which probably makes it a viable option. Your comment that "...I could use Core Data and have it talk to SQLite for me." suggests you might have somewhat misunderstood Core Data. Core Data is not a SQLite wrapper; it presents a completely different API, and uses its own schema. You can't really take a Core Data persistent store file and use it on other platforms unless you want to spend some time reverse-engineering the schema. Also, using Core Data with iCloud does not require the use of UIManagedDocument, though it does still require a lot of other Core Data-specific classes.
If you want to be able to sync data across multiple devices which are not all Apple devices then you need a third party API. None of Apple's cloud APIs will be useful here. There are many providers that can help out with this. For local data storage, either SQLite or Core Data would work, but you should look at the third party services and see what storage option(s) they support, then try to work with them.
The best approach depends on your needs. If you expect to copy data files from an iOS app to other platforms, SQLite is good. You'll still have a lot of platform-specific code, the savings there are much less. If you don't plan to move data files around like that, Core Data is probably easier to deal with.
I am starting to evaluate frameworks for a HTML5 app. I really like the enyo model for developing an app. However, my app needs an object-relational mapper (ORM) for local storage and some way to update the UI based on changes in the ORM data.
It looks like Ember has some great linkages for the ORM and update parts.
Has anyone used these two together? Does it makes sense or do either of them (by themselves) already address the entire problem space?
Thanks in advance,
Charlie
I've not tried to integrate them directly yet, but I think that the Enyo event model would work well here. Have the ORM live as a top-level component in your application and have it broadcast data change messages into your tree of components using enyo.waterfall() or enyo.waterfallDown().
I do something similar in a cryptogram game I'm working on where I use that mechanism to broadcast information about the player's guesses into the view tree where individual cells use them to modify their display.
How should a Windows 8 Metro application connect to a central database?
I've read about local storage, but I haven't read anything about connecting to a central database.
Obviously, this architectural design decision needs to support the disconnected scenario.
WCF web services seem to make sense.
But even if they do make sense, should we really create separate methods for all read/write operations?
Or are OData WCF services the way to go?
It seems like tablet software architecture should be able to borrow a lot from smartphone software architecture (but I am new to both).
Has Microsoft made any recommendations in its app samples?
It appears that others are asking similar questions on the Microsoft Developer Forums.
Here is what I've found:
According to Tim Heuer:
...You cannot directly have a SQL db embedded in your app or use
something like ADO.NET. This is more of an async/services
infrastructure. So if your data was exposed via services, then of
course you could connect that way. There are some other light-weight
methods you could use for local storage as well using things like the
Windows.Storage namespace (which is similar to Isolated Storage in
.NET).
Morten Nielsen agrees:
You can use HttpClient to download pretty much anything from the web.
Why don't you configure your WCF service to return data as JSON, and
use the DataContractJsonSerializer to deserialize the results?
Also, Tim Heuer cautions:
...Please note that while awesome, the SQLWinRT project on codeplex is a
wrapper to communicate with the classic SQLite engine...which uses
APIs that would not pass store validation currently.
Generic Object Storage Helper for WinRT and WinRTFile Based Database seem to have some promise.
But Daniel Stolt raises some good points:
It's awesome that there is good support for building OData clients and
other REST clients - but this only addresses the online scenario. The
"structured" part of Windows.Storage is a very limited model,
essentially limited to name/value pairs, insufficient for all but the
most basic scenarios. Yes there is local file storage, which is great
of course. But forcing every app developer out there to build her own
DBMS on top of local file storage will simply not cut it, especially
with all of System.Data having been removed from the profile. If local
file storage was sufficient for most device apps, then things like
SQLCE would have no purpose today already. And SQLCE clearly has a
purpose, and has played a very important role for occasionally
connected device apps for a very long time. There is also a tremendous
need for synchronization with a server-side database such as SQL
Azure, mostly to be able to roam data between devices. Yes there is
the roaming storage model in WinRT, but it shares the same limitations
of local storage mentioned above, and on top of this is very limited
in capacity (currently 30KB if memory serves). It is simply
insufficient for all but the simplest roaming data needs. Again,
forcing every app developer to design and implement her own
synchronization solution is very bad. You can do much better to enable
developers.
Many people are disappointed that the System.Data namespace is not supported in WinRT.
Richard Bethell said:
I don't even have words for this. This is astonishing. Leave aside for
the moment they want to force you to abstract to middleware for
database connectivity - I don't agree, but I can quasi understand a
rationale for that. I can even see pathways for developing like that.
But no System.Data.... at all? Do you even understand what you've done
to us?
What System.Data can do, outside of just having providers for Sql,
OleDb and other custom providers like Oracle, is provide a rich
abstraction of XML datasets that allow you to very quickly build a
data oriented Service Oriented Architecture.
For instance, I can easily create a web service using SOAP or WCF that
returns DataSets or DataTables, and then consume those objects easily
and directly. Being able to do this allows very rapid construction of
n-tier architectures, even without direct data connections available.
Without System.Data, and the power of DataViews, DataTables, etc. this
gets a lot harder. Sure you can custom create structs, put data in
there, and serve up structs, and use Linq to do whatever sorting,
filtering, etc. you want to do.... but it ends up being twice the
work, and makes code reuse a lot harder. And it means using our
existing service oriented architecture is impossible (without a big
overhaul.)
The withdrawal of System.Data is as big a thing for developers to deal
with as the loss of the Printer object in VB6 to vb.net 1.0 was. What
is harder to understand in this case is why it is necessary -
re-enabling it in the Metro profile can't possibly be a technical
difficulty of the product, can it?
It is valuable enough that I would seriously consider including Mono's
System.Data classes as part of any app I create (which would obviously
have to be open source.)
I think that this is another of those "it depends" questions...
The first and most obvious issue is that it very much depends on the context in which the application is running as to whether, to take the first case "Obviously...support...disconnected" is actually true - if the app is an internal corporate app then quite possibly not in that case no db == not work.
Secondly you could look (hmm, rash... one assumes you could look, this could be a bad assumption) at database synchronisation between a local SQL database and the remote db and so on and so forth.
Taking a step back... yes - you're absolutely right, look at it as being the same as phone or silverlight (although I don't know if there is yet RIA support) - but the thing is at this point its very hard to be prescriptive because given a general purpose platform one can therefore write applications to suit all sorts of purposes.
Not a hugely helpful answer really - but a start.
Having read #Jim G's answer it seems that I should probably withdrawn mine?