I'm not sure if stackoverflow is the best community to post this question, but it isn't clear if an appropriate community exists.
Some time ago I've joined the Multi-Device Beta Test feature on WhatsApp. Unfortunately, I've discovered several limitations, and the biggest one - being unable to access some older messages from Desktop anymore. For me it just says 'Use WhatsApp on your phone to see older chat messages'.
I still have the option of leaving the beta, and even though it will gradually be rolled out to all users, I would be very happy to use the older version for a little longer: this way I'll be able to back up my older messages.
My question is: if I leave the beta, what happens to my older messages (those that I can access only from my phone now), as well as messages received after enrolling in the beta? Will they stay intact?
As far as I understand, the older messages are stored only on my phone now, whereas newer messages are stored on Meta's servers. Will the older and newer messages be merged somehow, after I leave the beta?
Has anyone done this before and what were the findings?
Related
my Windows application which loads Google Contacts has been working fine for years. All of a sudden (probably within the last week or so) it's as if I've deleted all my contacts. All the Oauth2/ access token stuff seems to be fine (no error messages), it just loads zero contacts, with no recent changes to the code. Does anyone know if Google have changed something their end I should know about? I can't find any mention online.
The app uses older technology (built with MFC in VS 2008) but even so?
GC
My bad - I hadn't allocated enough memory to store the access token I was getting back from Google. But it might be of interest to know that they must have recently started sending longer ones...
So, I stepped once at this problem. I had offered a website that used the SoundCloud API. Everything worked properly. Content was extracted from the JSON and placed in the layout of the website. However, I received an email one day from the owner of the website, which indicated that the website did not work properly. I then came out to investigate and came to the conclusion that the "problem" was not on my side, but at SoundCloud's side. I studied on the API page of SoundCloud and came to the conclusion that the API had received a major update, making the link with SC and the site no longer worked.
Lately I'm trying many new APIs to, including those from Instagram and Dribbble. I was therefore wondering if it is at all possible to ensure that such problems can be reduced in the future or it might be appropriate API pages of this third-party APIs to monitor?
There's no "right" answer. After many years of using and maintaining many APIs here are some of the conclusions I've come to:
The best providers let you work with a specific version of their API whose interface and expected behavior never changes. They might release bug fixes and new endpoints, but you can be confident that as long as the API is supported it will not break your system.
A good provider will provide an end-of-life date for each version of their API. It's up to you to keep track of when you need to update.
Paid services will often be supported longer than free services. Plus the contract / SLA will guarantee it remains available for a specific amount of time.
The most popular APIs often have mailing lists and/or blogs. For those that offer it, sign up to be notified of updates. For those that don't you'll have to monitor their blogs or news posts. And I suggest not using any service that would drop support for an API version without warning.
In the past, I've been using the Delicious API available under feeds.delicious.com. When running this code today, I found out that the corresponding hostname is not available any longer (checked first time some days ago). I've already asked Delicious support directly about the state of the API, but not yet received an answer. So I thought anybody here might have more recent information, whether this is some temporary outage or the API has been cut completely?
This was likely part of the rollback to Delicious's old architecture in January 2016:
Fortunately for us, the version that the javascript site replaced has been kept alive at previous.delicious.com. This was built using a much more traditional framework, and it’s great! In fact, many of our longtime users have continued to prefer it over the main site, and frankly, so do we. Therefore, we are switching to this platform for our main site, and this transition will position us to quickly iterate in our ongoing efforts to keep Delicious thriving.
The auth URL on the documentation's OAuth page (delicious.com/auth/authorize) 404's for me as well, so I have a feeling this has indeed been retired.
I just started developing an Intuit App yesterday and was really getting going on integrating with QuickBooks Desktop. Then today I logged in to continue work and was greeted by several missing pages on Intuit's IPP site and a link that says "Deprecated QBO V2 and QBD V2,V3". The only API that appears to not be deprecated is QBO V3.
I cannot find any announcement from Intuit about any upcoming deprecation. Does anybody have any info on whether I am safe to continue developing my app to connect to QBD or do I need to talk to our accountant to move over to QBO instead?
EDIT: I have marked Jarred's answer as the accepted answer because he associated with Intuit and answers my specific situation. Also check Charlie's answer for additional details specific to other scenarios.
I interviewed several people from Intuit at the Sleeter Accounting Solutions Conference this week, including (amongst others) Dan Wernikoff, Senior VP.
I'll have an article in my blog on this (http://www.sleeter.com/blog/) next week - I'm transcribing my recordings and clarifying points.
There are a LOT of points here, but to address what you are looking at -
If you are writing an IPP app using V3 for QBO - no problem (and in fact, some good news there).
If you are already published with IPP using V3 and Sync Manager for the Desktop, you will get continued support but don't expect any advancement there (unless you are someone big like American Express).
If you are NOT already published with IPP for the Desktop - the SDK is your option.
And there is a lot more info about this coming out
MINOR EDIT AT A LATER DATE: If you have been working with IPP for the desktop you MIGHT get approved to continue - no guarantees on that (but it seems they might be lenient). But In my opinion you can't expect any significant new features (as in, more data access) moving forward unless you are a significant partner with a contract with them (such as, American Express).
Intuit will not prevent you from going live with your application that you have spent the last 6 months working on. We have a set of guidelines for grandfathering in developers who have invested in using the v2 REST API for QuickBooks Desktop.
feel free to contact me directly if you have more questions.
#Charlie if you could correct your statement regarding if you are NOT published then you need to use the QBXML SDK. That is too generic, we will evaluate each developer on a case by case basis.
regards,
Jarred
My writeup on this subject is available at http://www.sleeter.com/blog/2013/11/quickbooks-software-integration/
Note that Dan Wernikoff, Senior VP at Intuit, has been leaving comments in several of my articles in the blog.
Blair, you have a reasonable concern. However, given the REASONS that they made this change, I would SPECULATE that Intuit won't be pulling the SDK. What isn't clear, at this time, is HOW MUCH support they will give the SDK moving forward.
And, as we have seen for several years now, things can change...
I have a logistical question: I'm trying to figure out the best way to manage APIs getting out of sync with an app. The best way to explain it is with an example:
Let's say MyApp Version 1.0 posts to a "submit_feedbacK" API that requires first_name, last_name, and email.
I then submit MyApp Version 2.0 to the App Store. That version is designed to post first_name, last_name, gender, and email to the API. All of these are required fields on the API.
The problem I have:
- If I update the API before the new App is live, it will break Version 1.0
- If I wait until Version 2.0 is live and remotely cripple 1.0, I have to time it correctly.
I'm going to guess that the 'right answer' is to maintain two different APIs. But if both APIs post to the same live database, that makes things a bit awkward.
Does anyone have suggestions on how to model this?
This question may share some aspects with iOS consuming API design.
The right answer is definately to provide two APIs (at least for a short period of time while users adjust). You do not have to maintain two versions at the same time, as once a newer version is released you can maintain that one, and simply provide the old one for legacy users. The only real changes you may have to make to it are things like security patches or major issues. Major changes (such as you deciding to restructure your entire database) may lead to the old version not working any more, however update to newer API versions should be designed to allow previous versions to still function.
The other question I linked you to gives an answer about how you can have different version of your app access the correct version of the API.
Another note is that it may be easier for you (depending on what framework you're using) to design your APIs as engines or subapps, and simply mount them at different end points. I know that this is easily do-able in Rails by using Engines, and in Node with Express using app.use() with sub-applications.
I would use a webservice/http endpoint for the communcation with your app. If you preferer to maintain the same URL in all versions of the app, then include a version number in all the requests/posts to the server so it knows how to handle them. This will also make the development and tests easier as new versions can test against the new api on the server.
So on any function you can call in the webservice/server add a single variable with version number. a BYTE ought to be enough as I think you could start over and "kill support for v1.0" once you hit 256 versions of the same function (if ever).
Once the server receives a request/post with data, you can just code a simple switch/case structure in the server API so support works for both versions.
If they do similar, but eg. swaps the parametres or something, you can handle all these serverside and the BAL/DAL (n-tier structure) can be maintained on the server part of the solution.
Btw. my answer is not just for iOS or smartdevices, but merly a client/server approach for a "work-in-progress" production setup where everything has to be online, while still being under development and maintanance.
Hope it makes sense, otherwise, comment on it and I shall try to explain it further.
just FYI, I use CodeIgniter. I'm using the REST Controller provided at https://github.com/philsturgeon/codeigniter-restserver. I ultimated ended up settling on having different end-points for every version. Basically I'd check out a new repository for each release and put it into a unique directory. (i.e. http://www.mysite.com/1.0/api/method, http://www.mysite.com/1.1/api/method, etc) Trying to maintain multiple versions of an API under one code-base just sounded too scary. At least when I released a version, I would know it is locked in stone and I don't have to worry about breaking it. (Note: I had to use a special .htaccess tweak to get multiple CodeIgniter instances running from the same domain. I can share it if you like)