Hi There,

It seems this project is unable to get the version name/number of some applications. e.g: Instagram

The reason is these applications have different builds for special devices so they have a lot of builds for different devices and for this kind of application we are unable to get the latest version number I think it's really bad because we need to know what is the latest version number of each application since it's an important metrics to see applications updated or not.

Reported by @ATNoosh

Best,
M.

Hi there,

Gift

I'm here to say I will give a gift to anyone who can add this feature to the project and library.

Description

The feature is to fetch a list of reviews of an application. For example, we are going to fetch the list of all reviews one by one and handle pagination to fetch all reviews.

Sample page: https://play.google.com/store/apps/details?id=com.king.crash&hl=en&gl=US

Best,
M.

some time category return wrong id
"com.whatsapp" return kids category !!

array(6) {
  ["packageName"]=>
  string(12) "com.whatsapp"
  ["name"]=>
  string(18) "WhatsApp Messenger"
  ["developer"]=>
  string(12) "WhatsApp LLC"
  ["category"]=>
  string(4) "Kids"
  ["type"]=>
  string(6) "family"
  ["summary"]=>
  string(26) "Simple. Reliable. Private."
}

Hey,

If anyone is interested in doing this, we welcome it.

$app=$google->parseApplication("com.bezapps.flowdiademo", "en..");
$app=$google->parseApplication("com.bezapps.flowdiademo", "de..");
$app=$google->parseApplication("com.bezapps.flowdiademo", "fa..");
...

Thanks

The recent PlayStore redesign broke the parser nearly completely (apart from the app name, no fields had any data). I've fixed up most things with b837c52 (hopefully), but some things seem no longer available (e.g. the versionName of the last release, or the minimum Android version required).

@BaseMax would be great if you could check whether my changes work for you, and if you can find some of the missing details. I've left some comments in the code so you should be able to easily identify them.

Oh, and to make up a bit for lost details, I've added the video URL (what fastlane has as video.txt)…

hi i want to thank you very much for this usefull project
but today its stopped suddenly i think google play changed the api or something happen please can you update it ?

During my recent implementations and rewrites, I've introduced some "error reporting" to make it easier for the caller to figure if and what might have gone wrong. On error, several methods now return an array like

[success:0, message:"reason"]

But not all of them – for example, most of the search/browse methods supposed to return a simple array of package names don't have this. There would be two options to reach (a sort of) consistency:

• returning [success:0, message:reason] instead (and if so, include success:1 with a "good result) also for those methods that currently do not, moving the "real results" into a "sub-array" (which then, on error, could be empty or just not present at all)
• simply returning an empty array, and have a getLastError() method for obtaining the reason for all search/browse methods while keeping the current behavior for the others.

I'd prefer the first approach (so it's completely consistent) with the "empty real result". This combines the best of two worlds, e.g.

$apps = $google->parseWhatever();
if ( empty($apps['data']) ) { // this could simply mean nothing found matching the criteria
  if ( $apps['success'] ) { log('nothing found'); }
  else { log ('ERROR occured: '.$apps['message']); }
} else { // do something with the data

I'd even go as far as to always include the message key, just leaving its value empty on success. That would make things most consistent.

What's your stance? If you agree, I'd go over the entire class another time and make it consistent:

• success:0 only on errors – not generally on "no results" for a user-specified search (I vaguely remember I accidentally made it such in one case). message then holds the reason (e.g. the HTTP response, or parse error when an expected pattern didn't match, etc)
• success:1 on success. message then is present but usually empty, but might eg hold a hint on why the result set is empty (like "no hits").

If we want to fix it, we want to do that as early as possible – before there are users whose code would otherwise break on some update.