I've been unable to get weinre to work, I tried all the other solutions on the posts but cant see to get it to work at all. I have a very basic app, and the script seems to be injected into the code correctly (i unzipped the build apk).
- 3 Posts
- 0 Reply Likes
Posted 6 years ago
- 4116 Posts
- 192 Reply Likes
Hi Michael,
Would have a look at this and get back to you shortly.
May I know if you are building your app locally or using PhoneGap Build?
Do let me know.
Thanks.
Would have a look at this and get back to you shortly.
May I know if you are building your app locally or using PhoneGap Build?
Do let me know.
Thanks.
- 4 Posts
- 0 Reply Likes
This reply was created from a merged topic originally titled
Phonegap Debug is not working.
Hi, I think something is happening with the debugger. Since yesterday, the debug is not working. Can you check it please?
Phonegap Debug is not working.
Hi, I think something is happening with the debugger. Since yesterday, the debug is not working. Can you check it please?
- 4116 Posts
- 192 Reply Likes
Hi,
Replicated this.
We will look at this and hopefully can fix this as soon as possible.
Replicated this.
We will look at this and hopefully can fix this as soon as possible.
- 10 Posts
- 0 Reply Likes
This reply was created from a merged topic originally titled
PhoneGap Build Weinre: Not registering "targets" for debugging.
I have built my app, the app runs on my devices (Apple and Android) but nothing comes up in the Weinre debugging targets. It seems the devices show up under channels but nothing under targets.
We really need this for . .well debugging.
Please help! I have uninstalled the app, installed, cleared everything, made sure we are using current phonegap version (3.5.0)
My appID is 1021057
Let me know if this is something I'm doing wrong.
Thanks!
Austin
PhoneGap Build Weinre: Not registering "targets" for debugging.
I have built my app, the app runs on my devices (Apple and Android) but nothing comes up in the Weinre debugging targets. It seems the devices show up under channels but nothing under targets.
We really need this for . .well debugging.
Please help! I have uninstalled the app, installed, cleared everything, made sure we are using current phonegap version (3.5.0)
My appID is 1021057
Let me know if this is something I'm doing wrong.
Thanks!
Austin
- 28 Posts
- 0 Reply Likes
- 18 Posts
- 0 Reply Likes
This reply was created from a merged topic originally titled
Unable to Debug ios - weinre: target not connected.
I'm attempting to run the remote debugging tool per the instructions here: http://docs.build.phonegap.com/en_US/...
I've enabled debugging in the app, and have manually whitelisted both
http://debug.phonegap.com & http://debug.build.phonegap.com as I've found a few threads recommending this for ios...
Unfortunately, when I re-download the app, open it, and click Debug from the /apps page, I get Targets: -none
Any current ideas for this?
Thanks
Unable to Debug ios - weinre: target not connected.
I'm attempting to run the remote debugging tool per the instructions here: http://docs.build.phonegap.com/en_US/...
I've enabled debugging in the app, and have manually whitelisted both
http://debug.phonegap.com & http://debug.build.phonegap.com as I've found a few threads recommending this for ios...
Unfortunately, when I re-download the app, open it, and click Debug from the /apps page, I get Targets: -none
Any current ideas for this?
Thanks
- 4116 Posts
- 192 Reply Likes
- 18 Posts
- 0 Reply Likes
Great news. It'll be nice to have the functionality.
FYI the Target is now showing when I attempt to Debug, but I'm unable to click on it. Inspecting the target shows it as just text with no link attached (no href)
Thanks
FYI the Target is now showing when I attempt to Debug, but I'm unable to click on it. Inspecting the target shows it as just text with no link attached (no href)
Thanks
(Edited)
- 10 Posts
- 0 Reply Likes
Has there been any further progress on resolving this? or maybe an estimated date/time is will be fixed?
just curious :)
just curious :)
- 10 Posts
- 0 Reply Likes
It has been 7 days since original post of debugger not working. Has there been any further movement on solving this?
If not, has anyone successfully been able to install Weinre as an independent application and use it for debugging?
If not, has anyone successfully been able to install Weinre as an independent application and use it for debugging?
- 64 Posts
- 2 Reply Likes
I'm unable to get weinre working...
This combined with the geolocation and the ios push notifications no longer working, is it time to dump phonegap build and just build locally again?
This combined with the geolocation and the ios push notifications no longer working, is it time to dump phonegap build and just build locally again?
- 54 Posts
- 2 Reply Likes
I'm still unable to get the debugger working. Same issue as noted above. There are no targets being populated.
- 10 Posts
- 0 Reply Likes
@Ben Atack and gabaum10,
I would highly suggest instantiating Weinre on a self hosted service and not rely on PhoneGap's. Obviously it goes up and down all the time and they never even responded to my most recent inquiry about the issue nearly 2 months ago.
We host it ourselves and have never had a problem with it since, definitely the way to go
Good Luck!
I would highly suggest instantiating Weinre on a self hosted service and not rely on PhoneGap's. Obviously it goes up and down all the time and they never even responded to my most recent inquiry about the issue nearly 2 months ago.
We host it ourselves and have never had a problem with it since, definitely the way to go
Good Luck!
- 54 Posts
- 2 Reply Likes
@Austin, thanks. Yeah that's what I ended up doing. I just set up a local process to use Weinre. Was much easier then twisting the PhoneGap Build's guys arms to try and get them to figure it out. Apparently it's not an oft used feature, albeit incredibly useful.
I suggest if anyone stumble across this in the future to just set Weinre up themselves locally and use that instead of relying on PGB.
I suggest if anyone stumble across this in the future to just set Weinre up themselves locally and use that instead of relying on PGB.
- 4 Posts
- 0 Reply Likes
Really sad, weinre not working at all in PGB, even if it can be done locally, that is a waste of time that accumulates,
The team did not really listen to user feedback as full problem persists
The team did not really listen to user feedback as full problem persists
- 6 Posts
- 2 Reply Likes
more often than not, weinre comes back with a blank page. i reload 20 times until i get a page .. then i get along for while before it disconnects. for a payed product .. its pretty much unusable. is it me ?
- 6 Posts
- 2 Reply Likes
particularly, 'reload this page to reconnect' sounds way too optimistic :-/ more likely, first kill your app, then keep on reloading the page until it appears, then start your app again
- 54 Posts
- 2 Reply Likes
I've given up on this and just use the Chrome debugging tools, which are far and away better anyway.
https://developer.chrome.com/devtools...
https://developer.chrome.com/devtools...
- 1 Post
- 0 Reply Likes
Problem is, that only works for Android. Remote debugging with Chrome is not an option for iOS.
I stopped paying for PhoneGap Build a while ago and just making due with the 1 free app slot. It's tempting to subscribe again so I can get more app slots but there is absolutely no way I will consider paying for this product when the one feature I need the most is so unreliable.
I stopped paying for PhoneGap Build a while ago and just making due with the 1 free app slot. It's tempting to subscribe again so I can get more app slots but there is absolutely no way I will consider paying for this product when the one feature I need the most is so unreliable.
- 2 Posts
- 1 Reply Like
Weinre still not working. Been trying on and off for a few weeks. If Adobe have no intention to fix this they should remove the Debug buttons from PGB.
This was the only way I could debug iOS apps without a Mac and without connecting the iphone/ipad to our LAN. What a great tool now confined to the trashcan with no alternative replacement. Come on Adobe, show some love to your paying customers.
This was the only way I could debug iOS apps without a Mac and without connecting the iphone/ipad to our LAN. What a great tool now confined to the trashcan with no alternative replacement. Come on Adobe, show some love to your paying customers.
JesseMonroy650 (Volunteer), Champion
- 3325 Posts
- 122 Reply Likes
@Gary, Weinre is frustrating to say the least. It is not 100% reliable and sometimes the information is not worth much.
However, in future, if you have an issue with ANY phonegap things, it would be best to START a new thread and describe your problem there. When you do, please give us the following details:
* system you used
* the problem you are experiencing
* What steps you took before the issue you had
Also, we (the volunteers) know it is frustrating. We have experienced as much ourselves. So, you will get help, if you help us.
Best of Luck
Jesse
However, in future, if you have an issue with ANY phonegap things, it would be best to START a new thread and describe your problem there. When you do, please give us the following details:
* system you used
* the problem you are experiencing
* What steps you took before the issue you had
Also, we (the volunteers) know it is frustrating. We have experienced as much ourselves. So, you will get help, if you help us.
Best of Luck
Jesse
Petra V., Champion
- 7794 Posts
- 1391 Reply Likes
Jesse, it has been common use for years here to NOT start a new thread when an open thread covering exactly the same topic already exists. That is good practice, and helps those who use the search engine a lot.
The pgb support team works hard to merge various new threads into existing threads.
Please, don't frustrate this 'system' by suggesting developers to create new threads all the time.Let's try and keep this forum organized as much as possible.
The pgb support team works hard to merge various new threads into existing threads.
Please, don't frustrate this 'system' by suggesting developers to create new threads all the time.Let's try and keep this forum organized as much as possible.
JesseMonroy650 (Volunteer), Champion
- 3325 Posts
- 122 Reply Likes
I don't agree. That that is good, or the that is the case.
#1 The top of threads are marked. "Answered","Doesn't need an answer",etc. Doing as you suggest means that those threads, *marked* "Answered" or solved, will not be revisited - because the external marker says - it has been solved.
#2 If more than one person is complaining about the same issue, it is difficult to keep track of who is getting the answer, and who is not.
#3 Just because some says they are experiencing the same is DOES NOT mean they are - often the are beginners, and the results of trying to answer multiple people at the same time are frustrating.
#4 Search engines ARE NOT indexing old answer. PERIOD. It is well know that Google has filter parameters based on time. So, a prudent reader would filter out old answer! This defeats the strategy to *REUSE* old threads.
#5 We have move through 3 years in as many years. A phonegap 2.x answer is NOT good for a phonegap 3.x problem and so forth.
#6 My problem experience are because the end-user fails to read the documentation. Hence, they ARE NOT reading the old threads. So there is no argument that conclude that "new user" will read *OLD THREAD*. They are not reading in the first place - why are we wasting our time reading through old threads.
#7 BUGS get resolved. This means people asking questions about old bugs, are a waste of time - for both of us.
#8 We often get inadequate information about the users problems. We should encourage user to give us more and better information - NOT suggest they read out date threads.
Last, but not least. I recognize that some problems return, again and again, just because of the nature of the problem (bad docs, bad industry standard, confusing API).
So, if you have a GOOD argument for continuing a dated procedure - that minics the worst behaviour of StackExchange, then please enlighten me. Because I see NO sense in what you are suggesting.
Respectfully
Jesse Monroy, Jr.
#1 The top of threads are marked. "Answered","Doesn't need an answer",etc. Doing as you suggest means that those threads, *marked* "Answered" or solved, will not be revisited - because the external marker says - it has been solved.
#2 If more than one person is complaining about the same issue, it is difficult to keep track of who is getting the answer, and who is not.
#3 Just because some says they are experiencing the same is DOES NOT mean they are - often the are beginners, and the results of trying to answer multiple people at the same time are frustrating.
#4 Search engines ARE NOT indexing old answer. PERIOD. It is well know that Google has filter parameters based on time. So, a prudent reader would filter out old answer! This defeats the strategy to *REUSE* old threads.
#5 We have move through 3 years in as many years. A phonegap 2.x answer is NOT good for a phonegap 3.x problem and so forth.
#6 My problem experience are because the end-user fails to read the documentation. Hence, they ARE NOT reading the old threads. So there is no argument that conclude that "new user" will read *OLD THREAD*. They are not reading in the first place - why are we wasting our time reading through old threads.
#7 BUGS get resolved. This means people asking questions about old bugs, are a waste of time - for both of us.
#8 We often get inadequate information about the users problems. We should encourage user to give us more and better information - NOT suggest they read out date threads.
Last, but not least. I recognize that some problems return, again and again, just because of the nature of the problem (bad docs, bad industry standard, confusing API).
So, if you have a GOOD argument for continuing a dated procedure - that minics the worst behaviour of StackExchange, then please enlighten me. Because I see NO sense in what you are suggesting.
Respectfully
Jesse Monroy, Jr.
Petra V., Champion
- 7794 Posts
- 1391 Reply Likes
Well, let's go point-by-point, then.
1. The way threads are marked by PGB team is a problem in itself. Hang around here for a while, and you will see that many denizens are unhappily surprised by markers like "not a problem" or "solved", whene in fact the opposite is true. Luckily, denizens and PGB crew do return to marked threads.
A less than optimal marking of threads should not be reason to follow wrong procedures. That would make two errors.
2. If two or more users are complaining about the same issue, the answers are not indended for just one person. In fact, on a forum, every post is there to read and react to for everyone....even those who read stuff half a year later. It's not a one-on-one conversation.
Of course, a threaded forum would even cater for subthreads and a more individual conversation. But since this forum is linear, you could just say "Hi Jesse" if you want to reply to Jesse personally (or "@Jesse", as you like to do).
3. Results of trying to answer to multiple people are not frustrating. It just depends on how you are doing it. I've been involved in hundreds of such threads and can't say I feel frustrated.
4. You are probably refering to search engines like Google. I was talking about the site's search engine. That's where new denizens find (or at least are supposed to find) topics from the past. They search by key word. Should they really find as many threads as possible, or rather just the relevant threads?
5. I agree with your point #5. But that would just be reason to split threads when different PGB versions play a role. Not a reason to claim different threads based on "one problem, one user, one thread".
6. Your experience is based upon what users ask here. True, they have obviously not read threads from the past.
But....do you have a clue how many developers DO search for old topics and find their problem there? Who knows, perhaps the number of those who come and ask would have been much, much higher if there was no useable search function available.
For all those, who DO use the search engine, we should keep things clean and not fill this place with identical threads.
7. I agree...in a perfect world. However, bugs do not get resolved. Just find the github PGB bug list and see how many are still open from the past four years.
Another point, though, is: this forum is not really a place to post bugs (although posters won't really know in advance whether someting is a bug or not). PGB Support is doing a pretty good job by asking here, whene someone reports a problem, and then encourages the developer to post a bug report at github.
8. Exactly this is the point. If users supply incomplete information, we should ask the right questions. If they don't understand such questions, others may chime in....and they are more than welcome if it looks like their problem is identical. That increases chances of successfully solving a problem or explaining a solution.
We would exclude valuable information from other denizens and thus refuse the special benefits of such public forum.
A forum is not a ticket system (one user, one problem, one ticket), but a comfortable way for a many-to-many conversation about certain topics. The same topic, multiple participants, and hopefully one commonly accepted solution. That would be ideal.
1. The way threads are marked by PGB team is a problem in itself. Hang around here for a while, and you will see that many denizens are unhappily surprised by markers like "not a problem" or "solved", whene in fact the opposite is true. Luckily, denizens and PGB crew do return to marked threads.
A less than optimal marking of threads should not be reason to follow wrong procedures. That would make two errors.
2. If two or more users are complaining about the same issue, the answers are not indended for just one person. In fact, on a forum, every post is there to read and react to for everyone....even those who read stuff half a year later. It's not a one-on-one conversation.
Of course, a threaded forum would even cater for subthreads and a more individual conversation. But since this forum is linear, you could just say "Hi Jesse" if you want to reply to Jesse personally (or "@Jesse", as you like to do).
3. Results of trying to answer to multiple people are not frustrating. It just depends on how you are doing it. I've been involved in hundreds of such threads and can't say I feel frustrated.
4. You are probably refering to search engines like Google. I was talking about the site's search engine. That's where new denizens find (or at least are supposed to find) topics from the past. They search by key word. Should they really find as many threads as possible, or rather just the relevant threads?
5. I agree with your point #5. But that would just be reason to split threads when different PGB versions play a role. Not a reason to claim different threads based on "one problem, one user, one thread".
6. Your experience is based upon what users ask here. True, they have obviously not read threads from the past.
But....do you have a clue how many developers DO search for old topics and find their problem there? Who knows, perhaps the number of those who come and ask would have been much, much higher if there was no useable search function available.
For all those, who DO use the search engine, we should keep things clean and not fill this place with identical threads.
7. I agree...in a perfect world. However, bugs do not get resolved. Just find the github PGB bug list and see how many are still open from the past four years.
Another point, though, is: this forum is not really a place to post bugs (although posters won't really know in advance whether someting is a bug or not). PGB Support is doing a pretty good job by asking here, whene someone reports a problem, and then encourages the developer to post a bug report at github.
8. Exactly this is the point. If users supply incomplete information, we should ask the right questions. If they don't understand such questions, others may chime in....and they are more than welcome if it looks like their problem is identical. That increases chances of successfully solving a problem or explaining a solution.
We would exclude valuable information from other denizens and thus refuse the special benefits of such public forum.
A forum is not a ticket system (one user, one problem, one ticket), but a comfortable way for a many-to-many conversation about certain topics. The same topic, multiple participants, and hopefully one commonly accepted solution. That would be ideal.
So, if you have a GOOD argument....I have done my best, Jesse. We may not agree, but at least we are doing so based upon arguments. Good!
- 2 Posts
- 1 Reply Like
I've just discovered GapDebug. It brings live debugging and tinkering to both iOS and Android devices attached by USB to Windows or Mac. In particular for me debugging iOS on Windows is brilliant, and it's free. I wish I found this months ago.
https://www.genuitec.com/products/gap...
https://www.genuitec.com/products/gap...
- 1 Post
- 0 Reply Likes
Thank you! Actually works :)
Related Categories
-
PhoneGap Build
- 15111 Conversations
- 275 Followers










michael running wolf