I'm looking to use firebase's realtime database for a few different projects and if I select the 3rd and final subscription option it changes price per month based on usage ( if I'm not mistaken ). I want to make sure that if I choose this 3rd option of payment that it's something my app can provide sufficent funds for each individual user. Is there a way I can check how much the third option would cost based on recent usage or can I find out how much data it's currently using them I can manually compare them?
Related
It is also the first time to develop,
I want to make a diary app, but I don't know which database to use because I don't have basic knowledge of the database.
When I click on the calendar, I would like to post on that date
And I also need a picture that needs to be imported.
I can look for it even if I post this. I think it would be the fastest to ask. Thank you for reading my POST and hope everyone who reads has a nice day
Quick Answer: I would recommend persisting data on the users device instead of a cloud based database by using Core Data for the following reasons:
The content may be private or sensitive in nature, keeping it on the device is safer
Media attachments can become costly at scale, saving to device removes that burden from the developer
some cons of this route include the following:
Potential loss of Analytics by not using a cloud database such as Google Firebase
Cloud storage can be backed up in case the user loses their device (assuming they are not backed up via iCloud)
For a more thorough answer I recommend you provide more in terms of your objectives and audience.
The Apple App Store has some fairly strict requirements on what content an app can display and still meet the age ratings. I'd like to add a feature that can display content created by any 3rd party which means that, though "adult content" is not appropriate, it's not possible to guarantee that some spammer or vulgar person doesn't post inappropriate things.
I'm considering blocking access to that particular feature of the program for younger users.
How can an iOS app determine the age "category" of its user in order to choose what features to provide?
Other suggestions on how to deal with the issue of un-vetted 3rd party content is also welcome.
Ok so basically you want to know if there is a way to detect the users age and thus display certain features as is appropriate.
Well two ideas come to mind:
IDEA 1
You could try using the built in contacts API to see which contact the user has set themself as. If they have one, then check if it has a birth date. And thus figure out their age.
IDEA 2
Ask the user to enter their birth date in when they launch the app for the very first time. Then figure out the age and save it in a NSUserDefault. You can then use that value throughout the app to determine what features and posts to show the user.
I am looking for basically a repository of information regarding stores. Say I have an app, how would I find all the local stores that sell 'cellphones'? I have been using Google search to solve this but no luck. I know this is possible because through the use of Google maps or i-maps, you are able to find stores and public locations near you. I want to be able to find the store Items of a store. So i could for example say in my search in-app, "What stores will be selling PS4?". This will then display the location of all stores who will be selling PS4. I am not looking for code, I'm looking for data where this would be stored, like Data.gov etc...
Edit*
That's what I believed (#Naomi Owens), in regards to the item stock of a store. So since not knowing the stores current Item stock information, a go around would be to find all the stores that would seemingly sell that particular item and then based off assumptions and factual information regarding the release date of 'said item', notify the user that the queried item will be sold at those retailers based off assumptions. I guess you could then use a percentage system based off of 'logical assumption' the likelihood of a store selling that item. Example Walmart would have a higher likelihood (percentage) of selling a PS4 than would Fye (or some other smaller electronic store).
Locating nearby stores selling a particular product should be simple enough using Google API. The stock in these shops is constantly changing however and if such a database existed may not be very accurate. Each shop's stock, orders, customers etc. are located on their own private database which you wont have access to for obvious reasons. Many apps that do this type of thing do so through html scraping or xml parsing rss feeds. Neither of those would work in this case given that most shops do not use rss feeds and the large amount of html scraping that would be required otherwise.
Edit - I doubt that a database exists containing a list of all of a stores assumed stock, since the majority of people are only interested in live information. Sounds like a database that you would have to create yourself or pay someone else to create for you.
I have now played with the QBO and QBD APIs and feel I have a fair understanding of how it thinks and how to interact with it. So now it is time to design the actual integration solution.
Inside my application you can create new customers, quote services, perform services, and soon, pass invoices to QuickBooks, sounds easy.
But what if the customer is not in QB yet? No problem - for each invoice I will look up the customer (need the id anyway) and if it doesn’t exist, add it. But if I have to look up the customer for each invoice it seems like it might be slow. I will likely have 30,000 customers and have 500-3000 invoices per day.
So my question is this; what are others doing?
a) Are you storing the QB id for each customer in your data?
b) How do you detect address changes (changed in your app and changed in QB)?
c) Is the batch submission interface so much faster I should use that?
Thanks for your help!
We often times do store the QB id in our database for use. If we post an invoice into QB, we'll then store the QB id for future use if we need to modify it.
As far as detecting changes on the customer record and other info, there's a couple ways to handle the conflict resolution. One is to keep a timestamp on your side as to when changes are made. You can then compare this with the timestamp of the last change on the QB record and then make your decision as to which one gets updated.
FreddyMac,
To detect changes on the Intuit side you can construct a query with a CDCasOf Filter, which will return only the data that has changed since a date you provide. (ChangeDataCapture as of)
https://ipp.developer.intuit.com/0010_Intuit_Partner_Platform/0050_Data_Services/0500_QuickBooks_Windows/0100_Calling_Data_Services/0015_Retrieving_Objects
You need to keep track of data changes on your side.
The batch submission is not faster, its just easier for you to write the code.
The IPP SDK can queue the API calls for your and aggregate the responses.
regards,
Jarred
I have a strage requirement from a client, he needs to display a ramdom selection (100 - 200 items from mixed categories) of products for sale on & shipped by Amazon but ordered by price. The idea is to allow people find gift ideas based a user input price point.
I have been looking through the API docs but cannot see an obvious way to find search by price, I am thinking of writing a script to "copy" large parts of the amazon product catalogue into a local database & have it update every few weeks, then use this for user searches, but this does not feel right / their must be a better way.
Has anyone any experience with this type of problem? Thanks!
You would want to use the Amazon Product Advertising API. Using this API you would want to perform a SearchIndex-ItemSearch query. Possible parameters to ItemSearch are available on the API Docs here
You can see in the docs that you cannot query by MinimumPrice and MaximumPrice on SearchIndex: All. However, if you search specific indexes, it allows you to do a price related search.
I would guess that you can agree with your client which categories should the items be from. Then you can just query them one by one.
Amazon's database changes very often. Hence, caching data for a week without updating may not be desirable.