I already published an android app where you can see a list of specific objects and detailed informations about them. The list changes every day but some of the objects can appear again.
The application is communicating with a PHP server over HTTP and periodically pulls the list of objects.
I now plan to extend the app to make it possible to rate the objects and add a comment similar to how it is done in the android market. I'd like to avoid forcing the user to sign up for an account for being able to comment.
I see two problems:
The comment-system could be abused by spammers
A comment could be added from another system
So my questions are:
How to protect the system from spam?
How to authenticate the application with the server?
How do I limit the number of comments to one per user and object?
What about the androids device id? Is it unique enough to use it as identifier for the user?
Which other problems do you see?
2020 Commenting/Rating/Reviews Options
Since Socialize is out, here are a few options you can explore:
Build your own comment/rating implementation. Personally I love reddit and how it handles nested comments and ratings. Here's a library I found that implements it beautifully. Please note you'll need to tie this with a cloud-database. This is based on groupie. Article & implementation. Many ways to do this - https://stackoverflow.com/a/59472206/668240
Disqus - SDK's coming soon to iOS and Android.
BazaarVoice - commercial
Social Networks SDKs like Facebook, Twitter, etc. Personally I dislike this as we'll need to authenticate users with respective networks to use the APIs. It's like we are shipping off users of our apps to social networks. If you don't have a problem with that - then it might be for you
Legacy Option in 2014:
You can try out Socialize SDK which is open-source and a really good SDK for the rating and commenting you are looking for. It already has a well-functioning Commenting system built-in along with a 'like/love' facility and sharing to FB and Twitter. Each 'entity' (object in your case) can have metadata associated with it. So all you have to do is construct/use a rating widget, then send that rating with the entity attached to your object. To display your rating/comment is as simple as retrieving them from Socialize.
Each object (element from your app) should be associated with an entity which has a unique key in the form of a URL - sort of like a primary key to recognize your items. This entity can have meta-data - any data that you can insert on behalf of your object. Once you do that, you can retrieve that metadata any time you want.
I've been using Socialize for around a year now. They've matured over this period and are always aspiring to be the best at what they do.
Look at the Socialize Bar at the bottom. Its can be customized to your needs.
What's more - Socialize is free.
As for your questions:
There is comment moderation built into the Socialize Web Component
where you can filter out anything you feel is out of place.
Socialize allows you to authenticate through Facebook and Twitter.
Limiting to one comment per user can be achieved by using their User
and Comments API.
Socialize has both Anonymous authentication as well as Social A/c
authentication. I believe you can remove anonymous auth. So that
ensure that every user is authenticated before rating/commenting.
For authentication, you could use OpenID like StackOverflow does or Facebook authentication. Once you have them authentication, it shoud be easy to limit the number of comments to one per user per object. As far as spam, you could follow StackOverflow's model and allow users to vote comments up or down or flag as spam. Perhaps users with comments that have been voted up would have more power and be able to flag comments as spam.
You'll need some sort of rate limiting. I've used this one in this example before.
So you need a table with the user's ID and how many api calls they have left, and then when their last api call was. Then use the algorithm to update the values in the table every time a method is called.
Read through this, I think it should be possible to create an UUID for every case:
http://android-developers.blogspot.de/2011/03/identifying-app-installations.html
And then keep a hidden api key which is hard coded, or at least get's everytime calculated the same or in enigma style influenced by the time it is used. But you will be never be sure, that it won't be find out by crackers/hackers and maybe abused, you will always have this Problem.
Authenticate with the UUID of the user + api-key.
Related
I'm implementing a Firebase dynamic link mechanism in Android. We wanted to use Android SDK but to match users only when there is a one-to-one identification between users who clicks the link and user, which opened the app.
In iOS there is MatchType.Unique that serves this purpose:
The match between the Dynamic Link and this device is exact, hence you may reveal personal information related to the Dynamic Link.
https://firebase.google.com/docs/reference/swift/firebasedynamiclinks/api/reference/Enums/DLMatchType#unique
Unfortunately, I can't find anything close in Android SDK.
I will appreciate any help here to find how to distinguish deep links of the unique match type in Android
Thanks
It seems from this part of documentation that the matchType parameter exists only in Swift.
Personally, what I did is creating an array saved in the SharedPreferences, of all the DynamicLink already handled. Then, I just need to check for all the DynamicLinks entering if they are part of this array, and ignoring them in such a case.
Seems that even after an hour, the last DynamicLink handled still remains kind of "active".
So I'm developing a game for Android and I'm using Firebase for Authentication, to store user data, etc...
And now, I want to provide the user a way to share their score with their friends, so they can try to beat that score. I was thinking about sharing a dynamic link, and when the second user gets the link, the game would just start from that checkpoint.
But to do that, I would need to send a few data: the level Number, the first user's score, the first user's name.
I checked the documentation here and I saw that I can add some custom campaign parameters. But can I add those other parameters I need? If yes, How do I do it?
build Uri :
builder.scheme("https").authority("deepLink_from_firebase").appendQueryParameter("Param", Param_value).build();
and set that on setDeepLink()
To do this with Firebase, you would need to either encode all the custom data in the URL, or store it in your backend and use the URL as a key to retrieve the stored values. It's possible, but not as intuitive as you're hoping.
I would recommend investigating Branch.io (full disclosure: I am on the Branch team). The Branch service is free, does store an unlimited number of custom parameters with each link (exactly as you described), and interfaces perfectly with the other Firebase functions you are currently using. Branch links are used for this by many of the top apps in the world, including Airbnb, Pinterest, Tinder, and many others.
I am currently using api.ai , to create agent to perform specific tasks, but one question i don't have answer to is , can i make it learn something while chatting , mean that i speak my name is 'John Cena' and she should store it and then whenever i ask her again bot should answer me that. i know there is a way to do it by logging into api.ai web and manually add entries , but it will not help, is there any work around programmatically or automatically ? the file i've been using to practice is given in github . and here is working DEMO
You basically need for your bot to "learn" facts. There are many different ways to achieve this, but recently the most common way is to arrange knowledge into Semantic "Triples" and store the knowledge into a Graph repository (like Neo4j, Titan, Spark Graph, etc). In your example, "my name is John Cena" would translate into a Triple like ("anubava","Name","John Cena"). That way, the next time you are logged in as anubhava and ask "What is my name?", it would translate into a Graph search that will return "John Cena". A word of caution, achieving this is not trivial and would require some significant amount of fine tuning. For more info, you can check here and here.
Finally, most complete solutions (that I know of), are Server Side solutions. If you want for the whole knowledge base to reside in your mobile device, you could probably use the resources there as inspiration, and build your own Linked Data repository using an embedded database.
Hope this helps. Good luck.
To store and recall the user's name, you'll need to set up a webhook with some basic data persistence capabilities. Any database or key-value store would work fine.
Here's the breakdown:
Implement webhook fulfillment for the intent that captures the user's name. The webhook should store the name along with a unique, identifying ID that you should supply from your front-end in either the sessionId or as a context parameter in your call to /query.
Implement webhook fulfillment for the intent that reads the user's name. The webhook should look up the name by ID and return a response that tells the user their name.
The high-level docs for writing a fulfillment webhook are here:
https://docs.api.ai/docs/webhook
I can't seem to find any literature on expiring content with Android's App Indexing feature.
Let's say you have an app that shows users information on store sales. The store sales are time sensitive - they will eventually expire, and no longer be available. While the sale is available the user can see related search results because the app has used App Index to declare them. Eventually, the sale expires though. The content is presumably still in the App Index, but it's now dead from the perspective of the app.
How does one deal with this? Is there a way to explicitly remove content from App Index? Are App Index entries automatically expired if not declared again within a given timeframe?
The app index entries won't get expired on their own. They will be always visible in the history.google.com of that particular user. So you have to create a mechanism to gracefully handle your case. You can check for the timing in the code that handles the deep-link and take action according to that.
I believe the main question was how to remove deep links from App Indexing in the cases that the Web URLs linked is no longer available due to be time sensitive.
Now regarding your deep links to stop appearing in Google Search results, there are a few options to handle these time-sensitive issues:
1- Use the "unavailable_after" robots meta tag as explained here https://developers.google.com/webmasters/control-crawl-index/docs/robots_meta_tag?hl=en / https://googleblog.blogspot.it/2007/07/robots-exclusion-protocol-now-with-even.html
2- Add a noindex robots meta tag and inform Google about the page-change via the sitemap file
3- Just remove the page (or add a noindex), and Google will recrawl it after a while automatically.
Apart from this, I would recommend you to implement an exception handling for the cases that the App can not obtain any content from the server. You probably can use the HTTP error 404 for that.
I have an Android application that allows users to post information to a database, via a java web server that I have code on.
Users are allowed to up/down vote said post. How do I prevent the same user from voting a plethora of times on the same post?
A few ideas I had:
Disabling locally via adding a local storage "key" for the post ID Unique Key. For instance, when the user votes up or down. It writes a key with the information of the type of vote and the Unique Identifier of the post on the user's local storage. Is this feasible with a lot of votes? Would it cause any sort of hard drive consumption/lag?
Storing a uniquely-generated key on the user's phone generated at application install. This key would be submitted to a new table in the database that associates posts with votes and the "user-key".
If you're expecting lots of information, a database is probably the way to go. Obviously this will use storage space, but not much. Writing to the db tends to be very fast in my experience.
The unique key would work fine too. That way would be more secure (depending on how you do it) since it would be harder to spoof it from the client. If you generate the key based on the user's Google account, or the device ID, you're in good shape. If you do it by some pseudorandom method then the user could still cast multiple votes by just clearing the app data and getting a new key.
If it's really important to prevent multiple votes, do it on the server. If it's not particularly important, do whichever method seems easier to you. You can also consider doing both, for the best of both worlds: immediate feedback to the user on a duplicate vote attempt (or just altering the UI to make it impossible), plus a backup validation on the server in case the user tries to get around the client check.