I am new in android programming and now i have a problem to solve.
http://s3.imgimg.de/uploads/dbmodelcdcbb1fdpng.png
If you would code this Design like in the photo from beginning:
What kind of service would you use for this problem?
My MainProblem is to make a Service ( I dont´t have practice with) in "ItemListActivity" which saves all Incoming Data in DB.
The second big problem is, how "ItemDetailActivity" could access the Service to get data from DB?
THX and I´m very new to android so pls don´t just answer 1 sentence, it would be great if you can show me a little framework :)
The ItemDetailActivity should not access the service, it should work independently. All you should have to do is query the local database in the ItemDetailActivity and use the data from there.
all that other service should do is get the data and put it into the database. I recomment an IntentService for that
Related
I have a mobile App, done with Xamarin and I'm looking to implement the backend, but I'm lost because I have a specific need.
My app. should be able to do some "geolocalized" queries, by example :
SELECT * FROM MyProducts Where Category = "Fashion" ORDER BY Distance(Item.Position, Me.Position)
Do you see ?
Is it the way it works? For example, a famous mobile app. like Tinder are looking for peoples around you, is it the way they do that?
But so, for this, I need a database that supports such queries!
About performance, is there a difference with SQL and NoSQL database, pro & cons?
I was looking for Azure, because it seems to be the standard tool for Xamarin, but can't find any information about that kind of queries!
About other possibilities, I have seen... Firebase, etc... I don't know at all!
Any help is welcome
Thanks
From experience I can tell you that Azure does provide a few options that would allow you to work with geospatial data.
The first is Cosmos DB (DocumentDB) and it nicely integrates with Xamarin (https://learn.microsoft.com/en-us/azure/cosmos-db/mobile-apps-with-xamarin)
The second would be Azure Search. The advantage here is that you can use different types of data-sources to work with. (https://azure.microsoft.com/en-gb/resources/videos/azure-search-and-geospatial-data/)
I hope that helps.
I am developping an ASP.Net MVC 5 application that will be a SaaS for my clients. I want to use EF6 and I am currently using localDb. I am an Entity Framwork beginner and I am having a hard time learning it. I have been searching the web for the last 2 days, found different approaches but never found something clear for me that would answers my questions.
I followed Scott Allen Tutorial on ASP.Net MVC 4 and 5 so currently, I have 2 contexts, 'IdendityDbContext' and 'MyAppDbContext' both pointing to the DefaultConnection sting using a database called MyAppDb.mdf
I want my customers to be able to login on the website and connect to their own database so I was planning on creating a new ConnectionString (and database) for each of my clients and keeping one ConnectionString for my client Accounts information using my IdendityDbContext.
I have plenty of questions but here the 2 most importants ones :
1) I am not sure how to do that and test it locally. Do I have to create new data connections for all my clients and when a client connect, I edit the connection string dynamically and pass it to 'MyAppContext' ?
2) Even if I am able to do this, let's say I have 200 customers, it means I will have 201 databases : 1 Account Database (IdentityDbContext) and 200 Client Databases (MyAppDbContext). If I change my model in the future, does it means I have to run package manager console migrations command line for each of the 200 databases ? This seems brutal. There must be a way to propagate my model easily on every clients database right?
Sorry for the long post and thank you very much in advance.
The answer to (1) is basically "yes", you need to do just that. The answer to (2) is that you'll have to run migrations against all the databases. I can't imagine how you would think there would be any other way to do it, you've got 200 separate databases that all need the same schema change. The only way to accomplish that is to run the same script (or migration) against each one of them. That's the downside of a single-tenant model like you've got.
A few things you should know since you're new to all of this. First, LocalDB is only for development. It's fine to use it while in development, but remember that you'll need a full SQL Server instance when it comes time to deploy. It's surprising how common a hangup this is, so I just want make sure you know out the gate.
Second, migrations, at least code-first migrations, are also for development. You should never run your code-first migrations against a production database. Not only would this require that you actually access the production database directly from Visual Studio, which is a pretty big no-no in and of itself, but nothing should ever happen on a production database unless you explicitly know what's changing, where. I have a write-up about how to migrate production databases that might be worth looking at.
For something like your 200 database scenario, though, it would probably be better to invest in something like this from Red Gate.
I'm doing a system as my final year project, in university. My team members have different views on the development approach to use.
Does code first have more advantages than database first?
We'll be using mvc5 and will be deploying on azure.
Any feedback would be appreciated.
[Code-first vs Model/Database-first
This is for an older version but still valid.
We use code first but ultimately its an approach and you will find as many people for one as another. At University I was taught to design the database first as that was the methodology used to help structure it correctly and make you think through it. Now we use Code First but I approach things very differently to the Uni years as I have so much more experience. Its still EF at the Core so go with what complements your skills and maybe how you have been/are bring taught.
I would argue for database first. Why? Well, if somebody is designing the data model they are more likely to encode that model in the database.
If you opted for code first you will be modeling the domain (optimally) and then creating the database based upon conventions in the framework.
Once you have created the database you are back in first camp. Once it exists you will use code to access the data and not recreate your data model in the database.
I am developing an social app on iOS that have many-to-many relation, local persistency, and user interaction. I have tried using native Parse API in iOS and find it too cumbersome to do all the client-server logic. So my focus shifted to finding a syncing solution.
After some research I found AFIncrementalStore quite easy to use and it's highly integrated in CoreData. I just started to work on this and I have two questions to ask:
1) How to do the authentication process? Is it in AFRESTClient?
2) How to set up AFRESTClient to match Parse's REST API? (an example would be great!)
P.S. I also found FTASync, which seems to be another solution. Any thought on this framework?
Any general suggestion on client-server syncing solutions will be highly appreciated!
Thanks,
Lei Zhang
Back with iOS 5 Apple silently rolled out NSIncrementalStore to manage connection between APIs and persistent stores. Because I couldn't word it better myself:
NSIncrementalStore is an abstract subclass of NSPersistentStore designed to "create persistent stores which load and save data incrementally, allowing for the management of large and/or shared datasets". And while that may not sound like much, consider that nearly all of the database adapters we rely on load incrementally from large, shared data stores. What we have here is a goddamned miracle.
Source: http://nshipster.com/nsincrementalstore/
That being said, I've been working on my own NSIncrementalStore (built specifically for Parse and utilizing the Parse iOS/OS X SDK) and you're welcome to check out/use/contribute to the project at https://github.com/sbonami/PFIncrementalStore.
Take a look at this StackOverflow question and at Chris Wagner's article on raywenderlich.com.
The linked SO question has examples for how to include the authentication token with each request to Parse. So you'll just need to have the user log in first, and store their token to include it with each subsequent request.
Chris Wagner's tutorial has a sample AFHTTPClient named SDAFParseApiClient to communicate with the Parse REST API. You'd have to adapt it to be an AFRESTClient subclass, but it should give you a start.
Some other thoughts between the two solutions you're considering:
AFIncrementalStore does not allow the user to make any changes without a network connection, while FTASync keeps a full Core Data SQLite store locally and syncs changes to the server when you tell it to.
FTASync requires you to make all your synched managed objects subclasses of FTASyncParent, with extra properties for sync metadata. AFIncrementalStore keeps its metadata behind the scenes, not in your model.
FTASync appears not to be widely used and hasn't been updated in over a year; if you use it you will likely be maintaining it.
So here's my deal.
I'm using node on the express framework. The website i'm working on grabs scraped data and stores it for each user on the website. That data can then be displayed on the users page whenever they want to access it, so the data will be scraped, put in a database or storage, whatever i decide the best way to do it is, and then pulled back out for the user.
I'm trying to figure out what the best database setup would be. There will potentially be large amounts of data per user, especially over long periods of time. I've read some stuff about using redis to cache some data like the user login info and that basic stuff, and then using mongodb for the big data. But I don't know, i'm new to database stuff so I am open to some new teachings and some ideas from the masters.
What would you guys suggest I do? I want it to be fast and be able to handle multiple queries at the same time, but really, I have no idea what i'm talking about, so please help me.
What would you guys suggest I do?
This really depends on the nature of your data, how you model your domain and how you want to persist it. I would first try to figure out the basic model and based on that choose the most suitable database system. Don't jump at quick conclusions around caching with redis when you don't even know if you will need it in the first place.
Suggestion might also depend on how much time you want to spend with database layer of your application. Some database systems provide more functionality than others depending on their concepts. If you are a beginner choose a single mainstream solution that is well documented with established community like MongoDB or MySQL that will cover all your needs from the beginning so that you won't end up managing multitude of systems.