Find all packages by author

[JohnCoates]

Two things for this:

• Add "author: " operator to search engine so that you can find all packages by a certain author.
• Add a "More by this author" link under the "Author" link on this screen:

[iMokhles]

this page is an webview adding thing in it won't be applied to the current layout at all ( unless we hook WebKit and change the current HTML code there 🗡

[JohnCoates]

Ah, I didn't realize that portion was loaded too. Isn't the ability to modify website responses part of the public WebView API?

[iMokhles]

i never used it myself but seems we can do some sort of JavaScript manipulates to change codes ( but i'm not sure stringByEvaluatingJavaScriptFromString

[JohnCoates]

This is another good option:

You can return false, then retrieve the content yourself using NSURLSession (or NSURLConnection), and then inject the page into the web view by calling its loadData:MIMEType:textEncodingName:baseURL: method.

This approach will only work for page loads, though, not for other resources loaded by the page (CSS, JavaScript, etc.).

For a more complete approach, you can write a custom NSURLProtocol class. As long as you register that protocol globally, this approach should work for UIWebView classes. You might have to register the protocol class before you create the web view.

In your custom protocol, when you are asked to start a connection, you first make a mutable copy of the request and modify it in whatever way you want to modify it. Then, you tag the request in a custom way by calling setProperty:forKey:inRequest:, and finally, you re-issue the request using either NSURLConnection or NSURLSession.

In your canInitWithRequest: method, check to see if the request has already been tagged, and if so, return NO so that the normal HTTP/HTTPS protocol class will handle the request.

from http://stackoverflow.com/a/32601993

[kirb]

You can manipulate the DOM directly with WebKit’s objc bridge (avoid stringByEvaluatingJavaScriptString:).

Example – this adds a relationships link to the package page: https://github.com/hbang/Pheromone/blob/master/Relationships.xm

See also my ramble about this: https://www.reddit.com/r/jailbreak/comments/5dpq84/discussion_for_the_last_five_months_ive_been/da6h739/ – tldr, find some way to get any custom code executed on DOMContentLoaded, not load.

[JohnCoates]

Nice, looks like you've done a lot of what we're trying to do already. I think the best course of action is to fetch the content ourselves then hand off the prepared HTML to the WebView, that way we skip all that DOM stuff, and the solution is cleaner.

[kirb]

My worry there is that manipulating html as a string is a bit risky; the code might end up being more complex even if shorter.

[kirb]

Maybe a better alternative would be to host our own copy of the package page?

[iMokhles]

@kirb o thought about removing WebView completely and create a hole new UI with informations grabbed from the database ( still find solution for the commercial tweaks as well )

[kirb]

Overkill just for one or two buttons. Nothing wrong with the current solution, we just need to decide on how we’ll manipulate it.

[iMokhles]

yes but if we need to add more complex UI style changing colors and a lot stuffs would be useful your solution to host package page or create new UI using package information saved in the database

[JohnCoates]

@iMokhles Eventually a WebView replacement for tweaks that lack depiction URLs is definitely a good idea.

I haven't taken a close look, but can't we just load our version of the package page from disk, instead of hosting one?

[kirb]

That's what css is for. The web pages are there so they can be updated instantaneously; no need to recompile and release a binary for a small fix, consuming bandwidth on thousands of devices downloading a large binary when they could instead download a tiny text file. It'll take longer to develop something native when we could focus resources on more important functionality. Removing depictions would be a ginormous step backwards, wasting time on a new solution when the current one really has no problems.

I'm saying this because I've been here before. I once made a native package page proof of concept for saurik, and he rejected it and told me why it's a downgrade from the current solution. He might be super opinionated on the wrong things sometimes but his points there were absolutely valid/realistic. A redesign with html/css – he'd definitely consider merging that. A redesign in native code – no chance.

[JohnCoates]

That's good in theory, but how often has a small fix been pushed out like that? I feel that bundling a local copy of the design isn't going to hold us back at all, and it's good solution for now while we don't have hosting.

Overall, WebView apps are seen as sluggish, poorly performing, bloated, and full of small annoyances. The endless user complaints among other things pushed Facebook to move to native. The repo ecosystem relies on ad views for funding, so removing WebViews is out, but that doesn't mean we can't add a native package screen for special cases like when depiction URLs are missing.

As far as releasing a binary for a small fix, I don't actually see that as a problem. App Store apps are updated constantly for minor reasons, without consequence, and their updates are much larger that what ours would be. That's a worry better solved by QA, UI tests, and large scale beta testing.

[kirb]

We don't know because we don't necessarily notice it.

Apple has the infrastructure and the money to let companies release often; they provide hosting for millions of apps downloaded by millions of users daily. He's mentioned before that releasing a Cydia update costs quite a bit in bandwidth so we should take that into account.

Web views get a bad rep because Apple intentionally isn't invested in web. Safari is quite far behind the other browsers; Chrome has been pushing hard on features to make web apps feel better integrated. That said, Cydia works great on my iPhone 5 and iPad mini 2, and about as well as I'd expect on iPad 2. He made significant performance improvements some time ago. Is it still sluggish? Maybe I'm just used to it and don't perceive it, I dunno. But to me the performance point is a non-issue.

[kirb]

Also – bundling html in the app would be fine for now while we're still working on it. We're not guaranteeing stability right now and having to throw a server into the development process isn't necessary.

[JohnCoates]

I see solutions for these issues.

As for updates costing quite a bit. I have experience with BitTorrent, it's actually really easy to integrate. We could have a platform where people can opt-in to seeding packages on their computer or mobile device, and distribute releases that way. In fact it could be opt-in for downloading too, and it would be easy for repos to generate magnet links that get put into the package listings. It would be like a community CDN, and anyone who has extra server capacity can help out.

Again though, bandwidth wouldn't be an issue because the real solution to the problem of an unforseen small bug fix costing extra bandwidth is having betas. As far as I know Cydia doesn't do regular beta releases. There's 0 unit tests. 0 UI tests. What kind of QA process is there?

You really think that's Apple not investing in web is why web views get a bad rep? You're right, Chrome has been pushing super hard for this. They're the state of the art. So why does Atom, an app that's built on Chromium, get widely critized for being slow to launch, enefficient, and sluggish? That's an app that's being run on state of the art desktop computers that's still slow. An app that doesn't even rely on external resources. If that's the case for the state of the art, what hope do web view projects on mobile have for getting close to native performance?

I think you're very forgiving to Cydia. It's funny, many of us, after watching the Optimizing App Startup Time WWDC talk, started stripping shared libraries out of our projects for minuscule gains measured in milliseconds. Here I see big gains across the board. Let's take a cue from Facebook. I'm guessing you live in an area like most of us with plentiful Wi-Fi, 4G LTE, etc. Where I live there's a lot of LTE dropouts, so suddenly I'm on 3G or 2G EDGE, and the web doesn't load very fast. For most apps that's not an issue, for Cydia it's a huge issue. 69% of the world's population has 3G coverage (source).

Shall we see what that 31% of the world has to deal with when loading up Cydia's home page?

The wait? Thirty three seconds. That's for a single page. The most important page. The one that greets you on launch. Think we can improve that? I believe we can bring that measurement down to being measured in milliseconds.

If you'd like to test out these conditions here are the settings I used:

[kirb]

Important to note Cydia uses app cache. You can see 3 major states in that gif;

• First paint. Note all generic icons appear instantly.
• Ads appear. This is due to it being retrieved via xhr; a native implementation would be no different.
• Package icons appear. Obviously they aren't being cached. They definitely should be. The top logo is also a package icon. App Store also has the same issue.

As far as I remember, home isn't in the app cache. We should experiment with that; work out why it isn't. Because for instance, the package page appears almost instantly (and loads when offline) due to being app cached.

Of course, no matter what, on first run it must download all files in the app cache. On future runs the local cache is used initially and is updated in the background. Home page shows a progress bar when this happens. A potential way to "fix" the first run issue is to show a different, local, welcome page on first run, or load it behind the initial loading view controller (which I'd say should be done regardless of outcome). Can compromise and make the first run launch slower if it means guaranteeing no blank loading screens.

App cache has been around since iPhone OS 3, but too few sites use it when they should. I made Chariz Pay crazy fast using it. Next step is for me to use it for my entire repo.

Why is Atom slow to launch? I don't know enough about it to answer that. VSCode is significantly faster.

[JohnCoates]

Good solutions, but I'm against the premise. Home page literally never changes, there's no point in having a live load at all.

[kirb]

Fair point. Maybe a local copy of home and package could be fine; of course again bearing the bandwidth cost in mind if we don't go with a p2p sharing solution. Home has been used a few times to put out important notices (eg post-jailbreak release) so the existing home page with an xhr for grabbing notices and ads would be sufficient.

[JohnCoates]

Glad we're on the same page on this. Totally agree as far as being able to lazy load notices. That's good thinking.

As far as Atom, it's because web views aren't efficient. Agreed, VSCode is faster than Atom. Try comparing it to something native like Sublime though? Just for the sake of hopefully proving that native is currently much faster than web, for future reference and all: I measured VSCode, again a project based on Chromium, vs Sublime Text.

Attached is a reference video at 30 FPS, with frames measured.

VSCode

• launch: frame 46
• ready: frame 153
• total: 107 frames / 3.5 sec

Sublime

• launch: frame 402
• ready: frame 416
• total: 14 frames / 0.4 sec

Sublime is 7.6x faster to launch than VSCode. On the best web engine there is. If as you said, Apple is quite far behind other browsers and intentionally not invested in web, what hope do we have for having near native performance if we stick with web technologies?

vscode vs sublime.mov.zip

[kirb]

The perf isn't quite there yet, sure, but the typical user perception of web being slow isn't entirely the engine's fault. A lot of it is owed to lack of optimisation (not compressed/minified, unoptimised pngs exported from Photoshop, badly configured caching rules, render-blocking script/css, or just a plain ginormous site). Also, you're comparing our relatively simple pages to complex apps with endless lists of dependencies.

[JohnCoates]

I made the comparison because it's an easy one to make, with two almost identical, real world projects. Either way, we'll definitely stay with web views for now, but when we decide on a new design for the home screen I'm for having it implemented with auto layout.

Also you might want to remove your e-mail signature when replying to these threads, otherwise it includes a large chunk of text below your comment.

[ninjaprawn]

After doing some research within the code on how to do this (original idea):

Packages have a author and maintainer function. These return a class that holds both the email address and the name of the author/maintainer.

Note 1: afaik Cydia lists author then maintainer. So the search algorithm will have to check whether author is nil, and if so, check if maintainer is nil. If both are nil (which I don't think is possible), then we just ignore that package.

Note 2: When accessing these functions while searching/search button clicked, you have to call parse before your code

I'll have a POC soon (search field operator. web page will come if the search operator works as intended)

[JohnCoates]

Sounds good @ninjaprawn, look forward to trying it out!