I am using Datazen as my BI presentation layer. Since Datazen analysis comments does not support for Web browsing (as I know only support for mobile app). Is there any API we can call and send comments ?
No, Datazen does not offer any public APIs.
This is a feature request I've heard before (in one form or another), but yeah, unfortunately there's no known workaround either.
I'd keep an eye on product updates, and especially SSRS 2016 Mobile Reports. If the product team does choose to implement any APIs like this, that's where they'd go.
Related
With Google and other services transitioning to offer full server-side operability of their marketing & analytics products, I wonder when this functionality will arrive for Optimize?
Does anyone have any insights on that or can offer a possible workaround until it's officially supported?
The stated goal is, of course, to prevent loading third-party JS and the creation of non 1st-party cookies on a users device to enhance privacy and more easily control what data is sent where.
As I understand, server-side logic is currently limited to defining which experiment and version to show. The rest of the logic, like displaying the actual version or reporting back still require optimize.js to be implemented on the frontend.
Any help is dearly appreciated! 🙏🏼
I'm using this link https://www.google.com/reader/api/0/stream/contents/feed/FEEDHERE?output=json&n=20
to fetch feeds using Google's algorithm. As you can see I'm not adding any other parameters, just fetching the returned data in JSON format. My app will be heavily used hopefully and if I send a lot of requests to this link, will Google block my access or something?
Is there anything I can include, like userip, url for my app (so if they have problem to just contact me) or something else?
The most basic answer to your question is that Google will change its Terms of Service whenever it likes, and you've got no say in the matter. So if it's allowed today, it might not be allowed tomorrow, at Google's whim.
On this issue, though, you seem fairly safe. From the Terms of Service (these is the general document, since Reader doesn't seem to have a specific one):
Don’t misuse our Services. For example, don’t interfere with our Services or try to access them using a method other than the interface and the instructions that we provide.
Google provides RSS and Atom. They provide these feeds, so I assume they expect that they'll be used. They don't say that it's a misuse to point someone else at those feeds, so it looks OK for now, but they could add such a clause at any time.
All online services are subject to the terms and conditions of the providers of those services. So, as others have said, they may be ok with your use today, but they can change their mind any time down the line. I doubt including a URL or email or contact info will help anything, because when these services change, they don't notify every user of the service, they just announce the change publicly, and usually they give several month's notice in order to give users a chance to adapt their applications, but this is not standardized or enforced so there is no guarantee. One example would be the fairly recent discontinuance of the Google Finance API (for which no replacement has been announced).
The safest approach would be to design your app such that this feature that uses google's functionality is decoupled as much as possible from the rest of your app, so that, when or if the availability of the service changes (ie it's no longer available at all) you can adapt your app to use some other source for the feeds with minimal impact to the rest of the app. Design for change and plan for the worst.
I've looked all over and found nothing about this topic - For people making mobile app games and want to sell levels or potions or whatnot from within the app, is this supported on Flex mobile apps? Are there plans to introduce it? I've found info about advertisement implementation... is this a possible next step? Do you have to use something like PayPal instead of Android Market?
Sorry if this has been asked, but I haven't found anything yet.
Thanks!
I know Adobe said at GDC Conference they are in the process of analyzing requirements to make in-app purchases available via Flash Player API. It's almost a year so far since that announcement but there has not been any further news. The work around/the way most client-server implement these business rule is on the server-side where they implement an entitlements model.
Yes, there are several native extensions that implement this functionality.
I have been using the ones from Milkman Games with good results, and the support is fantastic. No financial association, just a very satisfied user.
There is also a free iOS Storekit ANE as well, although in my experience with it there are still some bugs, notably with blank receipt values for restored transactions: http://code.google.com/p/in-app-purchase-air-ios/
Note: implementing your own entitlements is ill-advised for various reasons:
Apple doesn't allow using anything other than their own in-app
purchase API on iOS.
The various store implementations (well, Apple's
and Amazon's at least, Google Play is another story) handle all of
the details of international purchases and localized pricing for
you.
The store implementations handle payments, subscriptions, durable purchases, and a host
of other details that you will spend a lot of time getting right on your own.
I need a custom multi-user multi-chatroom app to extend an existing Flex app that I have.
I obviously wouldn't like to develop it from scratch, but focus only on the customizations and integration.
Are there any products (free or commercial) that provide multi-chatroom functionality from which I could start?
http://www.adobe.com/devnet/flashplatform/services/collaboration.html
Have a look at Union Platform chat tutorial:
http://www.unionplatform.com/?page_id=1216
You can also check BlazeDS chat example:
http://livedocs.adobe.com/blazeds/1/blazeds_devguide/help.html?content=build_apps_3.html
I wrote an AS3 Chat Application that makes use of Player.io's free server package of 20 gigs of data transfer, other small limitations. The app is open source, and you can find the source code on GitHub.
The chat itself only uses one room, since it is averaging only around 10-15 users on at any time and its specialized to helping flash game developers, meaning it has a code storage area (simple database interaction), developer links, actionscript help, etc, but it does have some basic features if you want to see how I code them.
The chat itself has a few features you might be interested in checking out even if you don't use the source code, are such:
Support for authentication on server-side
Different types of users. (Currently overlord admin, admin, mod, developer, regular users)
Editable individual user data (Currently saves how long each user has spent on the app)
Server-side Silencing and banning individual users
Support for tags near usernames
Sound Settings on message received
Code box for users to share large amounts of text without spamming the chat
Support for multiple rooms (uses 1 public currently + 1 hidden for select users)
The server-side is written in C# and hosted on playerio.com and is supposed to be an authoritative server (meaning it checks all the client data and makes sure its valid before doing anything). The server code is also included on github.
If your interested you can comment and I will answer any questions.
I need to persuade management (product management and others) that just "publicising" internal private APIs is a bad idea compared to the best practice of creating a public API candidate, use it internally and when satisfied make it public. Can anyone help me find some facts like research papers that helps me make the argument?
I'm not aware of any specific research since the public interface to any API is highly subjective and specifically tied to a problem domain.
The first few pages of this pdf are an ok overview of an API for a business person:
http://aarontgrogg.com/wp-content/uploads/2009/09/How-to-Build-API-and-why-it-matters.pdf
This blog posts section header's highlight key points that your business partners need to think about as I think you're aware already. I would search for best practices around these specific subjects as they pertain to a public API: http://gaejexperiments.wordpress.com/2010/07/01/public-api-design-factors/
API Format Rest vs WebServices
Response Format XML, JSON
Service Contract Description
Authentication Mechanism for the Consumers of the API
Service Versioning (so you can roll out new versions of the API without blowing everyone up)
Rate Limits (obviously, for any number of things, preventing DOS attacks, and just managing system load)
Documentation
Helper Libraries
Website for the public api
Depending on what type of API it is... A SUPPORT TEAM
This doesn't address your internal processes either. Should your internal systems be able to evolve faster than the public api? In most cases I think the answer is yes, as your company wants to be agile with their business model and strategy. Having 3rd parties consume your internal systems is going to force your company to make a decision of who's more important when it's time to make an update. Either your company will have to version it's internal service and hope the third party consumers upgrade in a timely fashion, or just break the integration for all the third party consumers.
At the end of the day, it might not be worth doing. You can only screw over the people using your API so many times before they stop using it. What good is it if no one uses it.
I have been in the position before where the business has wanted an API pushed out too fast and without any governance around it. It resulted in all of my time being spent supporting people who were integrating with our API, and writing code samples for them.