my current project requires the implementation of Google StreetView.
The app already exists for iOS, where everything worked pretty fine, StreetView is embedded in the view, customized with overlays and buttons and what not...it runs fast, scrolling the StreetView view is smooth, it's obviously no webview...in short, it's perfect.
Now I have to do this app for Android and I was looking all day already, but with no success. From what I found out, there is the possibility to start StreetView as a new activity, without any chance to customize it, no overlays, no buttons, just standard Google stuff. This should be pretty smooth as it is not a webview. I can't use this, as I have to customize the UI.
Now I tried the webview approach and this makes everything slower and more laggy than you'd expect from even Android... BUT...seems to be customizable. Still, as slow as it is, I can't imagine anyone having fun with it.
So, my question is, do I have any more chances to get this working (a transparent Activity on top of the StreetView Activity? - please no)? Why does Google get it right for iOS and not for Android?
The iOS SDK just got released recently, is there a chance a new one will be coming for Android soon?
Thanks for any hints, M.
Found it. The answer lies herein : Android webview slow
Turning off the hardware acceleration speeds up the rendering ... yeah, right!
if (Build.VERSION.SDK_INT >= 11){
webview.setLayerType(View.LAYER_TYPE_SOFTWARE, null);
}
Related
Someone asked me to create a website for his sportsclub, I decided it try and make this webpage in ReactJs.
https://complexbjj-2a19b.firebaseapp.com/ this is the outcome, looks pretty and
works well on desktop.
It's pretty responsive layout wise.
So I was pretty happy untill I decided to build and deploy for production.
Sadly I found out that the webpage wasn't optimised for phones at all, leaving random blank spaces.
I tried allot of things, changing to PureComponents, Using React.memo.., etc etc.
Nothing seems to help, so now I'm here after hours & hours of trying to find a solution with my hands in my hair.
Does anyone know what could be causing this problem?
If you have the Google Chrome browser installed on your machine, you can try auditing your app in the inspector Audits tab (here is the doc). That could help you spot possible improvements.
I've to share a mobile screen and display it on a browser using WebRTC. I then have to take control of the mobile screen.
I've researched this and know I can share a screen browser to browser using chrome(with extension) or firefox(after certain flags are set). Some information I've read suggests that screen sharing on mobile is not possible and then another article said it was but I think they meant be sharing through the chrome browser on a mobile.
Some of the the information and posts I read are dating back to 2013/2015/2016 and I wondered if there is any new information on this?
Is screen sharing on mobile devices(android or iOS) possible using webrtc now?
is screen control on mobile devices possible?
Thanks Andrea
I also investigated this topic a few days ago and it seems to me we are on the verge of the next step and the technology hasn't totally settled yet. Screencapture is mostly working with (very) up-to-date browsers and (still) an extension or some kind of white-listing. I could not find any kind of hint that a "remote control" mechanisms are part of webrtc and the getUserMedia implementations. Unfortunately.
ICE seems to work fine for most scenarios (if you don't mind waiting a minute) and Tickled ICE adresses the problem in an interesting way.
Mobile is very confusing indeed as the market is even more heterogeneous.
Maybe we should open a wiki or a chat channel or whatnot they habe nowadays on stackoverflow :-) I think I will have to read about this "community wiki" checkbox down there...
The most promising thing I could find was
https://inthelocus.com/
Still trying it out in different scenarios.
[This might not be an answer...] I was on the same topic and then I noticed there's an existing tool (SDK) to serve the similar purpose: https://cobrowse.io. It works good in both the demo video and the simulator web page. Yet I'm not sure if it utilises WebRTC...
So I wired in Prettify.js and Prettify.css into my new Tumblr blog. It works out great in chrome, IE, and Firefox but I was astonished when I went to my Android Phone and suddenly the code inside ... looks like an atrocity.
I was about to go digging but figured before I spend hours trying to solve a problem someone else already fixed I would see if my ol' Stack Buddies have anything to say on the matter.
aquamoogle.tumblr.com
Any solutions will be greatly appreciated and if none are posted I'll likely toss up a solution by the end of the weekend.
Clarification EDIT This is viewing the post through the Tumblr Android application. I don't think it has anything to do with phone version but because someone is bound to ask it's a Motorola Droid Bionic running Android 2.3.4
Alrighty, since nobody came along with this one I'll throw the answer out there. The Tumblr application after decompiling it off the APK does not use a standard web frame. This means that javascript execution is not embedded in the view for the mobile application.
Sucks I know... Another possible solution would be to use straight CSS for formatting but alas this doesn't even work in the mobile version as the CSS sheets are overridden with mobile style sheets for more compact formatting.
So this one goes down as "unsolvable" due to the mobile application not operating within the same boundaries as the web driven blog does.
If someone does by chance have a solution to this that will work however, I would be interested in hearing it but at this time I don't have a valid solution. But, it's good to know.
Sencha Touch is brilliant but IE cannot open websites which is developed using Sencha Touch.
I am not interested in using IE, but my opinion is not important since many others may use it.
Since Microsoft announces HTML-5 Support and I have worked with the great tools to make native apps even using HTML-5 and Java so it is obvious that IE 10 must support HTML5. But it seems sencha touch websites cannot be explored by IE 10 too, since I cannot explore Kitchen Sink (on sencha.com) using IE 10 however I can easily do this using Chrome.
Further to this problem, I want to make an web-site for a small company, is it right to use Sencha Touch to develop it or jQuery is a better choice? (I yearn for you say Sencha Touch :) since I am completely unfamiliar with jQuery)
I appreciate the time you are spending.
Sincerely yours,
PEYMAN MORTAZAVI
Call me old-fashioned, but when I see the Kitchen Sink demo failing in IE10, I blame the developers behind the demo, and not those behind the browser. IE10 is an oustanding browser that is worthy of our attention, and not merely for the fact that it will be used by millions upon millions immediately following its official release, but also because it's a great browser from a technical perspective.
If you're going to build a solution for your clients, you should avoid libraries that wish to distance themselves from supporting half of the market, meaning they don't actively develop with IE in mind. The excuses for not supporting IE simply aren't there today as your code won't require that much variance to work properly in the latest version of Microsoft's browser.
Use jQuery, jQuery Mobile, or jQuery UI. You can get some great UI from and with all of them, and you'll find excellent support in all major browsers.
I am porting my Sencha Touch 2.0 app to 2.2.1 in order to support IE10.
So I have first-hand knowledge in the effort.
all Sencha websites / apps build previous to 2.2.0 and by developers targeting webkit browsers will never work on ie10 reliably because a bunch of stuff had to be done to the core of Sencha Touch in order for ie10 to work. Everyone has to go back and do what I'm doing... line by line of CSS and a few JS changes as well (esp if you do canvas stuff)
Running an old "kitchen sink" which was not properly architected for 2.2.1 and tested on IE10 is not going to work either. I do not know how much time Sencha folks spent testing kitchen sink on IE10 ...but one would assume...
I think what has thrown Sencha for a loop is developers don't have time or money to build business apps twice - once on ExtJS for laptop/desktop and 2nd time on Sencha Touch 2 for tablet touch/gesture support. This is the strange land of SDK's because the tablet real-estate so closely resembles that of a small laptop -- ergo as long as your UX people a really good, they can architect an experience that crosses over from tablet to laptop pretty good by building one code base in Sencha Touch.
But oooops - Sencha figured we'd all be building to small phones - a market dominated by webkit browsers. If that were the case, then this argument of IE market share would not hold - we all know Windows Phone numbers. It's hard to fudge/spin that. What's causing the rub is the tablet-laptop screen size being so similar.
IMHO...
IE10 in the Windows 8 preview is the same version that is slated for the tablets and mobile devices they have been producing. Saying it is for desktop support is not a very useful statement. The problem is this is what Microsoft is about to spend a very large amount of money marketing and pushing to businesses. This is not a case of a tablet/phone library not supporting a desktop, but of a tablet/phone library not supporting a target platform that is about to have billions of dollars of marketing spent to deploy it.
Any mention of Internet explorer seems to evoke deep emotion in everyone! However IE is a fact of life.
I would suggest that you use Google Chrome Frame. The first time IE visitors arrive at your site you can alert the user to install Google Chrome Frame and redirect them. It's a bit messy for the first visit but after that it should be seamless.
As I understand it Google Chrome Frame no longer requires admin rights to install.
Obviously people should just install Chrome in the first place but nobody's perfect.
Sencha Touch 2 is not designed to work on IE10. If desktop support is important for you, then you should use Ext JS 4.
Chrome and Safari use WebKit which Sencha Touch requires in order to function.
Internet Explorer might be able to display Sencha Touch apps in the future:
http://www.appleinsider.com/articles/08/11/06/microsofts_ballmer_considers_using_webkit_within_ie.html
http://www.favbrowser.com/opera-firefox-and-internet-explorer-to-implement-webkit-prefixes/
But who knows?
I had spent a month getting a project to work with Sencha Touch, but had to choose a more accessable framework. The goals of the project were to work across as many browsers (desktop and mobile) as possible. The webkit preference for Sencha, while admirable in how it is achieved, made it unusable for my needs.
I am glad they changed their licensing since I tried it. That was the second stumbling point for our project.
Is there anything that is less intimidating than recaptcha for mobile apps? My app is built with JQuery Mobile and most likely will never be available on the desktop. I am hoping there is a more visual captcha that would not require typing. So far most visual captchas I have found seem too large for a mobile app. I am mainly looking for something that is visual and small enough to fit within the average mobile screen. Any suggestions would be appreciated, I would even be willing to build something from scratch if someone has a good idea.
I don't know if you are using HTML5 or not, but there is a pretty cool captcha that I've used called MotionCAPTCHA. What it does is it presents a shape and the user traces the shape with their finger on their mobile device. Its pretty cool. I've used it with Android and it works pretty well. It requires jQuery and HTML5.
Damn, that MotionCAPTCHA link appears to be dead. I found this question looking for similar things to what we're working on at my current company.
We have a HumanDetect mobile SDK trying to solve a similar problem. The overall idea is we grab sensor data from the phone so we can determine "bot or not". You ask the SDK for a token, then send that token along with your REST request, and then that token can be validated. If everything works as expected only a mobile device in the hands of a human should produce a token that validates as "not a bot".
It's native code, not using the browser. For the end-user's point of view, it is transparent, the user isn't asked to perform any action.